Config changes to avoid JMS thread deadlock

Question

          From various postings and Weblogic documentation I'm trying to understand the specifics
          of
          how to avoid a JMS thread deadlock problem. The Performance and Tuning Guide states
          "...consider a servlet that reads messages from a designated JMS queue. If all
          execute threads in a server are used to process the servlet requests, then no
          threads are available to
          deliver messages from the JMS queue. A deadlock condition exists,...". I believe
          that is
          what I have, and am trying to understand whether the solution is to create a separate
          execute queue for the servlets, or change the settings on the Execute and JMS
          Thread queues,
          or both, or something else, and if so, what are the settings I should use?
          Specifically, I have servlets that use connections to a custom resource adapter,
          and each
          custom adapter connection writes to a single (for all adapter connection instances)
          permanent JMS queue and reads a response from a one-per-adapter-connection temporary
          queue. Messages are read from the permanent JMS queue by a client process (running
          outside of WLS). My servlets use the default execute queue - i.e., the don't use
          a custom execute queue - and my reads on the temporary JMS queues are timing out,
          I believe because
          no threads are available to process the JMS message
          So can I avoid deadlocks by:
          1. creating a custom execute queue that has n threads
          2. allowing a maximum of n custom adapter connection instances
          3. Setting my JMS thread pool to n (assuming I have no other JMS activity)
          i.e., using the same number - n - for all three settings? I'm about to try this
          and see,
          but if it works I'd still like to have a better understanding as to why (and of
          course if it doesn't,
          I need that understanding even more).
          Or, is text somewhere describing the specifics of how all of the Weblogic thread
          queues
          and JMS play together? There seem to be pieces scattered in various Weblogic documents,
          but
          nowhere have I found a single, coherent and complete description of how all of
          these factors
          interact.
          

Answer 1

          Tom Barnes <[email protected]> wrote:
          >Thanks for the info. Allocating the servlets to their own execute queue solved
          my problem.
          >
          >Glen wrote:
          >
          >> From various postings and Weblogic documentation I'm trying to understand
          >the specifics
          >> of
          >> how to avoid a JMS thread deadlock problem. The Performance and Tuning
          >Guide states
          >> "...consider a servlet that reads messages from a designated JMS queue.
          >If all
          >> execute threads in a server are used to process the servlet requests,
          >then no
          >> threads are available to
          >> deliver messages from the JMS queue. A deadlock condition exists,...".
          > I believe
          >> that is
          >> what I have,
          >
          >You can often verify by inspecting a thread dump. Note that there
          >are other possible reasons for dead-lock, including
          >programming errors at the application level - and if that is
          >the case, the thread dump will likely reveal that as well.
          >
          >> and am trying to understand whether the solution is to create a separate
          >> execute queue for the servlets, or change the settings on the Execute
          >and JMS
          >> Thread queues,
          >> or both, or something else, and if so, what are the settings I should
          >use?
          >>
          >> Specifically, I have servlets that use connections to a custom resource
          >adapter,
          >> and each
          >> custom adapter connection writes to a single (for all adapter connection
          >instances)
          >> permanent JMS queue and reads a response from a one-per-adapter-connection
          >temporary
          >> queue. Messages are read from the permanent JMS queue by a client process
          >(running
          >> outside of WLS). My servlets use the default execute queue - i.e.,
          >the don't use
          >> a custom execute queue - and my reads on the temporary JMS queues are
          >timing out,
          >> I believe because
          >> no threads are available to process the JMS message
          >>
          >> So can I avoid deadlocks by:
          >> 1. creating a custom execute queue that has n threads
          >
          >yes, or configuring more threads for the default pool
          >(somewhat more than you have concurrent servlets)
          >
          >> 2. allowing a maximum of n custom adapter connection instances
          >
          >no - i think your servlets would just end up blocking waiting
          >for adapter connections (instead of blocking waiting for
          >response messages)
          >
          >> 3. Setting my JMS thread pool to n (assuming I have no other JMS
          >activity)
          >
          >i'm not sure, but I don't think this will help in your case - JMS
          >uses the JMS thread pool for a limited purpose, and
          >still uses the default thread pool otherwise (as documented in
          >the perf guide). Plus the default thread pool is needed for
          >RMI/timers/etc.
          >
          >If servlets are truly "stealing" all of the default threads,
          >I think the best option is give
          >the servlets their own thread-pool.
          >
          >> i.e., using the same number - n - for all three settings? I'm about
          >to try this
          >> and see,
          >> but if it works I'd still like to have a better understanding as to
          >why (and of
          >> course if it doesn't,
          >> I need that understanding even more).
          >>
          >> Or, is text somewhere describing the specifics of how all of the Weblogic
          >thread
          >> queues
          >> and JMS play together?
          >
          >The JMS performance guide
          >white-paper is probably the best resource at the moment, it seems
          >to be pointing you in the right direction (provided you confirm
          >the problem is thread pool limits)
          >
          >> There seem to be pieces scattered in various Weblogic documents,
          >> but
          >> nowhere have I found a single, coherent and complete description of
          >how all of
          >> these factors
          >> interact.
          >
          >You are welcome to email a suggestion to bea support.
          >Customer suggestions tend to have more weight than internally
          >generated suggestions.
          >
          >