Geek Answers Handbook

Long time solutions for Java EE?

The problem that I have encountered several times in my career is the multilevel service architecture, when one downstream system can bring down the entire client application if it falls into a state where all its threads are consumed in a dead end or in some form of an endless loopback error in this system. Under these conditions, the server socket on the Java EE server still accepts requests and queued requests from client applications. This forces the client application to use all its threads, waiting for responses from properly established socket connections. Then all users are blocked from the system, as their requests are also in the queue.

I thought of a few solutions, but I was wondering if the community has some of the best.

  • Isolated thread pools for subsequent requests. This becomes a problem because you combine the number of unallocated threads on your system, creating many small pools that need to have enough threads to ensure full throughput. Spawning threads means you need to deal with transaction and security contexts yourself. Not really supported Java EE solution.

  • The MDB solution, the preferred asynchronous solution for Java EE, however, it looks rather heavy, but has the added advantage of allowing the application server to manage MDB thread pool management. (Currently number one on my list)

  • ESB This is even heavier weight and adds more time to the network and processing. But it allows you to set individual service timeouts. In addition, the problem is that it will take forever to infiltrate a large corporation, so it’s probably not practical for my time frame.

Do you guys have any better ideas?

+4
source share
3 answers

You are correct that the MDB package is a common solution, and it usually supports timeouts that will help to prevent query hangs. However, this may not solve the problem, but simply move the backup to the JMS queue without replies being sent back to the client. Of course, if only one of several services causes this problem, the rest will now be available.

Your suggestion (1) can also be executed in WebSphere or Weblogic through the commonj WorkManager. This will allow you to create managed threads in these environments and is quite easy.

API WorkManager and TimerManager

+1
source

We use MDB, where the queue is stored in a database, which has the advantage of not losing messages if the system goes down.

You can also establish an asynchronous contract between the parties involved. What I mean is that the client will send you a message and instead of doing a lot of heavy weight processing and returning an answer, you just send a confirmation response and later send an asynchronous message with them with full results.

You must also establish a protocol that allows the client to resend the message if they have not received a full response within the set time.

0
source

You can try the easy MDB approach with Atomikos MessageDrivenContainers (MessageJriven POJO). Your application will be lighter, better testable, and probably more scalable.

Cm. http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

NTN

Guy

0
source

More articles:


All Articles