0

Our organization has bunch of code (C, C++, Java) that runs on Tandem (non-stop) and serves the business needs. It's a mission critical environment dealing with around 80 to 90 Requests per second.

I am completely new to the Tandem environment but they way I understand from the folks who developed the code is that their Java code runs in a single threaded mode. Basically they spawn multiple pathway processes and each pathway contains multiple JVM processes. The mindset of a developer working under that environment can be assumed to be "single-threaded".

My team has been given this task to move this code to run under JBoss (which is multi threaded as we know) which already runs an application, the idea is to finally merge the Java code from Tandem into our existing.

It is important to know that due to political reasons, we have decided to perform a "lift and shift" as the first step and will later deal with this application in terms of merging this application to work under existing JBoss app in a true multi threaded fashion.

We are thinking of running this code (which is an independent component) as a stateless session bean along side with our existing application. The existing application doesn't use any EJB or Spring / hibernate and works very well. Based on the way SSLB works, we are assuming that one object of SLSB would be accessed by one thread at any given point of time. The worry is however static variables which are inherently not thread safe. I understand our approach is not 100% correct and need advice on what are possible ways to deal with this.

The important point is to get the ownership of the code asap and make it working in production in some way and then later deal with complexity of the real code and slowly merge it with the existing application.

Are there better ways of dealing with the situation given the constraints? Any design inputs would help.

Prakash
  • 73
  • 3
  • What is the reason that this code must run under JBoss instead of just in a similar workflow running on the new operating system? – Thorbjørn Ravn Andersen Jan 18 '16 at 06:44
  • This is the last remaining piece of software that needs to migrate. JBoss because that's where the current app runs, which is missing this particular piece. If run outside, I have to basically do exact same as was done under Tandem, spawn multiple JVM's, build a router which would spray load across. This would basically add lot of complexity, I would rather go through the business logic and rewrite it to run under multi threaded environment. – Prakash Jan 19 '16 at 05:09
  • By moving inside a servlet container, you are missing the "clean slate" when restarting the JVM part and you will need to fix that, as well as all the rewriting needed will introduce bugs where none were before. My gut feeling is that you understand this code base too little to do this now - as this is mission critical, the chance for having subtle issues showing in production is too big. Question is why you have to do this _now_? If it is to get rid of the tandem, then strongly consider building a replica to get experience. – Thorbjørn Ravn Andersen Jan 19 '16 at 05:45

0 Answers0