I was surprised to see that the whole Landing Page configuration surrounding DNodes changed completely from 7.2 to 7.2.1, but my initial concern surrounding this is has more to do with controlling this new JVM, as it is independent of the Tomcat start/stop process, and I did not see anything in the manuals that talk about this new process.
is there a provided safe mechanism to start/stop this JVM?
I am on Tomcat, but what can I expect to see when I move to a WebSphere or WebLogic environment, is this still just going to be an external Java process?
so on WebSphere/WebLogic, there will be an external Java process started up as a result of creating a Node for VBD/DataFlow/ADM/DDS, explicitly not an internally configured AppServer Controlled JVM ?
and to control the Node, we must start/stop it using the Decisioning->Infrastructure->Services Landing page ... there is no externally provided start/stop, to that this can be scripted?
I have tried this on a Tomcat server, and I had to stop (in order) the ADM Node, the DataFlow Node, the VBD Node, and lastly the DDS Node before the process goes away ... so 4 separate (manual) GUI commands to control the process. and of course this then triggers a number of errors in the log file before the Tomcat server itself is stopped, which brings PRPC down.
The good news is that on restart of the AppServer, the Node does restart itself, and the Cassandra Java process exists once again.
so ... my follow-on questions are, how can this process be safely stopped in a scripted fashion ... and if it is controllable via script, should it be stopped before or after the AppServer JVM's ??
I can see that architecturally this is a better way to run the service, than inside the PRPC JVM, as it alleviates the issues of how to cluster PRPC JVM's as you can only have 1 Cassandra node on a physical host (single IP address).
Not a DSM expert, but I notice that there is a cassandra/bin directory (for tomcat, right under <tomcat> directory), which has all the tools, including nodetool described in the operations guide. As for the reasons of a separate process, I believe you are right, perfomance (separate memory space in particular from that of prpc instance) is definitely one of the top reasons if not the only reason. I can also see the benefit of starting/stoping cassandra service without having to restart prpc instance.
yes, I looked at that directory, and I can see the cassandra (start) script plus the stop-server script, it would appear that PRPC now includes a full (separate) Cassandra install with all the client tools too (for issuing CQL3 queries). the guidance just says to kill the cassandra server for the stop process, and I know that restarting the Tomcat server will initiate the start of Cassandra again. I guess I was just hoping for some documentation describing these architectural changes, and guidance with best practice. The DSM Operations guide skims the surface of the Cassandra Configuration, and seems to recommend that you read the datastax doc'n.
We have seen performance issues with using Cassandra for Delayed Learning (7.1.9 & 7.2), so I am convinced that this is a performance feature, but was hoping for that to be clearly spelled out by Pega.
Also, I have only installed this on Tomcat thus far, and was seeking clarification on what to expect with WebSphere & WebLogic, so that we can help out customers in a knowledgable fashion.
In a nutshell, Cassandra is now an external Daemon, and is not part of the PRPC Server any more.
It starts up when you configure a DDS Node on the Infrastructure>Services Landing page, it does not stop when the PRPC Server is brought down, but you can safely send the process a kill command. The Cassandra Server will start back up when the PRPC server is restarted.
While I have not definitively told so, this is most likely a Performance Improvement, as we have observed the load Cassandra adds to the PRPC JVM in previous versions.
So, you now have an external Cassandra Service which you have the option to fully configure using normal DataStax/Cassandra config, if you choose to do so. You also have all the client tools, so you are ready to issue CQL3 queries at Cassandra without having to install the tools yourself.