users@glassfish.java.net

Re: java.nio.channels.ClosedByInterruptException on JMS message send from long-running SLSB

From: Steven Siebert <smsiebe_at_gmail.com>
Date: Thu, 14 Jul 2011 12:05:36 -0400

Update: I changed to inline JNDI lookups to the ConnectionFactory and
generate the connection as needed. Same problem, but it feels like it took
longer to error (although I didn't time things).

Same error (JMSException caused by
java.nio.channels.ClosedByInterruptException) but this time the connection
id's are different between each request (so I can see that it's requesting a
new connection on each call).

Snippet of my error:

javax.jms.JMSException: MQJMSRA_DS4001: JMSServiceException on send
message:sendMessage: Sending message failed. Connection ID:
7580738126500288000
<blah stack trace>
Caused by: com.sun.messaging.jmq.jmsservice.JMSServiceException:
sendMessage: Sending message failed: Connection ID: 7580738126500288000
<blah>
Caused by: com.sun.messaging.jmq.jmsserver.util.BrokerException: transaction
failed: java.nio.channels.ClosedChannelException

The JMS server is on the same JVM/GlassFish instance as the app is running.

S




On Thu, Jul 14, 2011 at 11:01 AM, Steven Siebert <smsiebe_at_gmail.com> wrote:

> Hello,
>
> I use JMS extensively throughout one of my EE projects and have noticed a
> problem when using them with long-running EJB operations (ie scheduled
> tasks). I'm hoping it simply a mis-configuration or improper implementation
> I can easily remedy =)
>
> Basically, I have a SLSB that uses resource injection to nab a
> ConnectionFactory and Topic for my topic. Within these EJBs, I have long
> running tasks that make remote SOAP calls, process results, use JPA to
> store, blah blah...lots of time. When processing starts, everything runs
> smooth. JMS messages make it to the topic, etc. Eventually, I get a
> java.nio.channels.ClosedByInterruptException from jms, killing my
> transaction (which is what I want as far as the transaction goes, but not
> what I want as far as the untimely death part).
>
> I believe what is happening (please correct me if I'm wrong) is that the
> connection eventually times out due to it's long running (despite it's
> continued, though sporadic, use throughout the task). If this is the case,
> I suppose I could grab a connection using JNDI when I need it instead of
> using resource injection as an EJB instance field. This way, I would let
> the pool manage the connections and only serve me good connections when I
> need it. The only down side is that I would be nabbing connections more
> frequently...but I'm not really too worried about that since it's pooled.
>
> Thoughts?
>
> Thanks!
>
> Steve
>