WebLogic JMS Connection Is Not Thread-Safe
(Doc ID 2205666.1)
Last updated on JULY 31, 2023
Applies to:Oracle WebLogic Server - Version 22.214.171.124.0 to 126.96.36.199.0 [Release 12c]
Information in this document applies to any platform.
Our application, deployed in WebLogic Server 188.8.131.52.0 domain, uses Spring's org.springframework.jms.listener.DefaultMessageListenerContainer to fetch messages from WLS JMS Queue.
DefaultMessageListenerContainer uses a single shared JMS Connection and multiple JMS sessions dedicated to each worker thread.
A bootstrap procedure for JMS resources within DefaultMessageListenerContainer is as follows (simplified):
1. Fetching JMS Connection Factory from JNDI context
2. Creation of the single shared JMS Connection in a stopped mode
3. Concurrent execution of:
3a. Start of multiple worker threads which create JMS Sessions using the shared JMS Connection (at this point JMS Connection is in a stopped or running mode - that depends solely on the relative timings between threads)
3b. Start of the shared JMS Connection
What can be rarely observed is the incoherent state of the shared JMS Connection after the bootstrapping procedure is finished: JMS Connection is started but some of its JMS Sessions are still stopped.
This behavior is very problematic since Spring's container can't receive messages through JMS Sessions that are stopped.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document