You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Vishu <vk...@yahoo.com> on 2006/07/12 21:00:41 UTC
activemq from C++ application in linux and window
Hi,
Am completely new to Java. I have application written in C++ and it is
ported on Linux and Windows. I want to use Activemq from my application
which can work on Linux and Windows platform. Can someone advice me quick
solution
Thanks in advance
vishu
--
View this message in context: http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-tf1932905.html#a5295304
Sent from the ActiveMQ - User forum at Nabble.com.
Re: activemq from C++ application in linux and window
Posted by Vishu <vk...@yahoo.com>.
Hi Sanjeev,
We have similar requirement in our app. We have JNI C++ function to call
java code, java code intern talk to ActiveMQ. C++ app is multithreaded and
will be calling java code using JNI C++ function.
What are the issues can come up in multithreaded environment.. Can I use
same java object of JavaVM, JNIEnv, jclass, jmethodID, jobject from
different threads which was initialize in my main thread
Thanks in advance,
Vishnu
--
View this message in context: http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-tf1932905.html#a5392162
Sent from the ActiveMQ - User forum at Nabble.com.
Re: activemq from C++ application in linux and window
Posted by Sanjiv Jivan <sa...@gmail.com>.
We've done some profiling and haven't found the marshalling over JNI to be
significant for our requirements, especially with JDK 1.4+.
btw does ActiveMQ C++ handle network byte ordering when client / server are
on machines with different byte ordering?
Thanks,
Sanjiv
On 7/13/06, Timothy Bish <ta...@twcny.rr.com> wrote:
>
> Sanjiv
>
> You design does sound interesting. Its been awhile since I've done any
> JNI
> coding. As with anything there are tradeoffs that you make when you go
> that
> route, as I recall marshalling between contexts can be a big hit to
> overall
> app performance, but at the end of the day, if it meets your requirements
> then you can't complain to much.
>
> As far as the cross platform threading issues go, we have created a fairly
> nice Threading implementation in the new activemq-cpp that resembles java
> threading in its use, and has been tested pretty heavily on Windows and
> Linux, we still need to hit OSX and Solaris.
>
> -------------------------------------------------
> Timothy A. Bish
>
>
> -----Original Message-----
> From: Sanjiv Jivan [mailto:sanjiv.jivan@gmail.com]
> Sent: Thursday, July 13, 2006 7:29 AM
> To: activemq-users@geronimo.apache.org
> Subject: Re: activemq from C++ application in linux and window
> Importance: High
>
> In our project, we embedded a JVM in the C++ app, and exposed methods for
> inbound -> C++ delegation and C++ --> JNI method to send messages using
> the
> JNI RegisterNatives function. This helps us do all our jms configuration
> using Spring and also keeps the messaging code in Java. The ActiveMQ
> java-java communication seemed more mature than the C++ portion and it
> also
> kept us away from cross platform threading issues associated with C++
> apps.
>
> Any comments on this approach?
>
> Sanjiv
>
> On 7/13/06, Nathan Mittler <na...@gmail.com> wrote:
> >
> > Hi Vishu,
> > comments inline ...
> >
> > On 7/13/06, Vishu <vk...@yahoo.com> wrote:
> > >
> > >
> > > Hi Nate,
> > > Thanks a lot for your response.
> > > Sorry for bug you again asking stupid questions
> > > My requirement is something like. There are two applications one main
> > > application (App1) written in C++ and second application (app2)
> written
> > in
> > > Java. Where App1 will be publishing messages regularly (the no may be
> > 1000
> > > message per second or more) these messages need to go to Activemq and
> > App2
> > > should be able to subscribe for those message.
> >
> >
> > I see no problems with the data load, in our testing we were sending
> > several
> > thousand messages all at once.
> >
> >
> > I need a persistence
> > > messaging no message should be lost. Because App1 and App2 are running
> > on
> > > different m/c?s and may not be running at the same time.
> >
> > But looking at
> > > http://www.activemq.org/site/activemq-cpp-roadmap.html
> > > There is known issue
> > > After committing a transaction, the consumer seems to stop getting
> > > messages
> > > after around 999/1000 messages. We think this is a bug at the broker,
> > but
> > > more investigation is needed.
> >
> >
> > It may be worth noting that this test was done from C++ client to C++
> > client
> > which may have different results than going from Java->C++. So it may
> be
> > worth your time giving it a shot as you should be able to set up a test
> > fairly quickly.
> >
> > Also I don't know whether they have had any release of ActiveMq C++
> > client,
> > > I did not find that on web or is it yet to be released it is still
> under
> > > development.
> >
> >
> > There is no official release yet, as we're still doing some cleanup
> before
> > we begin to port the openwire C++ client. I'm guessing that once we get
> > openwire in, we'll begin to be incorporated in the mainline release
> cycle
> > with the rest of AMQ.
> >
> > --
> > > View this message in context:
> > >
> >
>
> http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-
> tf1932905.html#a5302652
> > > Sent from the ActiveMQ - User forum at Nabble.com.
> >
> >
> > Regards,
> > Nate
> >
> >
>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
Al the code resides in on JVM - we will change this in the future, we
will have a standalone process for an ActiveMQ browser so we will use
TCP/IP connection latter.
Well, I don't know about fatal errors in the transport, but the
connection is not closed(as you can see in my last posts) the connection
is cleaned up(close sessions, stream ,listeners) but the session remains
connected.
The only thing that occurs just before I get "Session close" is this
exception :
I think I will do like that :
I will store one session in a ThreadLocal and use that to create
consumers and producers. Both operations will catch the first exception
and recreate the session again so only the second failure is propagated
up. So in this case a connection cleanup will not be a problem.
Also I will active activemq loging with debuging and everything I will
get I will post it here.
Thanks again.
2006-07-15 03:24:54,628 [AcitveMQ Connection Worker: vm://localhost#0]
ERROR com.daxtechnologies.sams.manager.SamsManagerJMS - JMS Error
javax.jms.JMSException: Interrupted.
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
at
org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
at
org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)
at
org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
at
org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
at
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
at
org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
at
com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
at
com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
at
com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
Caused by: java.io.InterruptedIOException: Interrupted.
at
org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
... 23 more
James Strachan wrote:
> On 7/18/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> Hi James,
>>
>> Again I use VM connector so no failure should happen.
>
> So all your code resides in a single JVM right? There is no TCP
> whatsoever?
>
>
>> But anyway that's not a problem with the failure, the big question is
>> why the connection is cleaned up when a transport error occur
>
> What else could we do other than close the connection and throw an
> exception if the transport goes bad.
>
>
>> and what's
>> the approach here, is not clear for me in case of transport failures,
>> the connection release the sessions and next time I will get "Session
>> close" when I'm trying to create a consumer.
>> What should I do? in case of an error first try to recreate the session?
>
> So first try and diagnose what is causing the failure. So turn on
> debug logging. Or create a local build of ActiveMQ which dumps in big
> flashing letters the exact error which is causing the transport to be
> closed - something is causing the session to close and its 1 single
> Java class, so you should be able to add logging code in there to tell
> you exactly what is causing it. Then mail us the stack trace and
> interesting bit of your log.
>
Re: Session closed after a while(random)
Posted by James Strachan <ja...@gmail.com>.
On 7/18/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> Hi James,
>
> Again I use VM connector so no failure should happen.
So all your code resides in a single JVM right? There is no TCP whatsoever?
> But anyway that's not a problem with the failure, the big question is
> why the connection is cleaned up when a transport error occur
What else could we do other than close the connection and throw an
exception if the transport goes bad.
> and what's
> the approach here, is not clear for me in case of transport failures,
> the connection release the sessions and next time I will get "Session
> close" when I'm trying to create a consumer.
> What should I do? in case of an error first try to recreate the session?
So first try and diagnose what is causing the failure. So turn on
debug logging. Or create a local build of ActiveMQ which dumps in big
flashing letters the exact error which is causing the transport to be
closed - something is causing the session to close and its 1 single
Java class, so you should be able to add logging code in there to tell
you exactly what is causing it. Then mail us the stack trace and
interesting bit of your log.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
Hi James,
Again I use VM connector so no failure should happen.
But anyway that's not a problem with the failure, the big question is
why the connection is cleaned up when a transport error occur and what's
the approach here, is not clear for me in case of transport failures,
the connection release the sessions and next time I will get "Session
close" when I'm trying to create a consumer.
What should I do? in case of an error first try to recreate the session?
James Strachan wrote:
> It sounds like for some reason your transport is being closed due to
> some kind of network issue. Generally if your code is not doing it
> then the only time a session is closed is if the transport fails with
> a serious exception.
>
> So I'd
>
> * enable debugging logging to watch the networking code and look for
> errors/reconnections
>
> Does your application run in a single JVM? i.e. there is just 1 JVM
> with all the code inside and no TCP is being used at all? If not it
> sounds like networking is failing such as a socket or inactivity
> timeout or something - so either change your failover: configuration
> or disable the inactivity timeout
>
> http://incubator.apache.org/activemq/configuring-wire-formats.html
>
> On 7/18/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> Anybody, please :) I don't know how to continue with this issue ...
>>
>> Adrian Tarau wrote:
>> > Any thoughts ???
>> >
>> > Adrian Tarau wrote:
>> >> I think I found the cause???? :)
>> >>
>> >> Look at this stack trace(which seems to be the source of our
>> >> problems, after this exceptions we got "Session close"), which at
>> >> some moment in time I got it(see bellow - I will mark with bold the
>> >> what's important). Look at the bold stack entry, in
>> >> ActiveMQConnection.onException.
>> >> Un unrecoverable error in transport close the sessions, consumers,
>> >> listeners , etc but doesn't close the connection.
>> >>
>> >> My question is how can I avoid getting the "Session close" message?
>> >> How can I test if the session is closed? It is this the right way to
>> >> handle a transport error, cleaning up the connection?
>> >>
>> >> I cannot test if the session is closed(ActiveMQSession.closed field
>> >> is private), eventually I can try to do something with the session
>> >> and in case of failure, I will recreate the session. Is this the
>> >> right way to do it?
>> >>
>> >> Thanks.
>> >>
>> >> /**
>> >> * An unrecoverable exception has occured on the transport
>> >> * @param error
>> >> */
>> >> public void onException(final IOException error) {
>> >> onAsyncException(error);
>> >> asyncConnectionThread.execute(new Runnable(){
>> >> public void run() {
>> >> *transportFailed(error);*
>> >>
>> >> ServiceSupport.dispose(ActiveMQConnection.this.transport);
>> >> brokerInfoReceived.countDown();
>> >> for (Iterator iter =
>> >> transportListeners.iterator(); iter.hasNext();) {
>> >> TransportListener listener = (TransportListener)
>> >> iter.next();
>> >> listener.onException(error);
>> >> }
>> >> }
>> >> });
>> >> }
>> >>
>> >> and then transportFailed
>> >>
>> >> protected void transportFailed(IOException error){
>> >> transportFailed.set(true);
>> >> if (firstFailureError == null) {
>> >> firstFailureError = error;
>> >> }
>> >> if (!closed.get() && !closing.get()) {
>> >> try{
>> >> *cleanup();*
>> >> }catch(JMSException e){
>> >> log.warn("Cleanup failed",e);
>> >> }
>> >> }
>> >> }
>> >>
>> >> and then cleanup
>> >>
>> >> public void cleanup() throws JMSException {
>> >> if( advisoryConsumer!=null ) {
>> >> advisoryConsumer.dispose();
>> >> advisoryConsumer=null;
>> >> }
>> >> for (Iterator i = this.sessions.iterator();
>> i.hasNext();) {
>> >> *ActiveMQSession s = (ActiveMQSession) i.next();
>> >> s.dispose();*
>> >> }
>> >> for (Iterator i = this.connectionConsumers.iterator();
>> >> i.hasNext();) {
>> >> ActiveMQConnectionConsumer c =
>> >> (ActiveMQConnectionConsumer) i.next();
>> >> c.dispose();
>> >> }
>> >> for (Iterator i = this.inputStreams.iterator();
>> i.hasNext();) {
>> >> ActiveMQInputStream c = (ActiveMQInputStream) i.next();
>> >> c.dispose();
>> >> }
>> >> for (Iterator i = this.outputStreams.iterator();
>> i.hasNext();) {
>> >> ActiveMQOutputStream c = (ActiveMQOutputStream) i.next();
>> >> c.dispose();
>> >> }
>> >>
>> >> if(isConnectionInfoSentToBroker){
>> >> if(!transportFailed.get() && !closing.get()){
>> >> asyncSendPacket(info.createRemoveCommand());
>> >> }
>> >> isConnectionInfoSentToBroker=false;
>> >> } if( userSpecifiedClientID ) {
>> >> info.setClientId(null);
>> >> userSpecifiedClientID=false;
>> >> }
>> >> clientIDSet = false;
>> >>
>> >> started.set(false);
>> >> }
>> >>
>> >> *Stack trace*
>> >>
>> >> at
>> >>
>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
>>
>> >>
>> >> *at
>> >>
>> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)*
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> >> at
>> >>
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> >> at
>> >>
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
>>
>> >>
>> >> at
>> >>
>> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
>>
>> >>
>> >> at
>> >>
>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
>>
>> >>
>> >> at
>> >>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>
>> >>
>> >> at
>> >>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>
>> >>
>> >> at
>> >>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>
>> >>
>> >> at
>> >>
>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>
>> >>
>> >> Caused by: java.io.InterruptedIOException: Interrupted.
>> >> at
>> >>
>> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
>> >> at
>> >>
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
>>
>> >>
>> >>
>> >> Adrian Tarau wrote:
>> >>> Even more :)
>> >>>
>> >>> As I told you I created a a Session wrapper over the ActiveMQ
>> >>> session in order to catch the close call.
>> >>>
>> >>> you can see down bellow the close method :
>> >>>
>> >>> public void close() throws JMSException {
>> >>> try {
>> >>> IllegalAccessError illegalAccessError = new
>> >>> IllegalAccessError("I don't want to close");
>> >>> StringWriter sw = new StringWriter();
>> >>> illegalAccessError.printStackTrace(new PrintWriter(sw));
>> >>> LOG.error("Somebody closed the session, let's see
>> >>> who\n\n" + sw.toString());
>> >>> System.out.println("Somebody closed the session, let's
>> >>> see who\n\n" + sw.toString());
>> >>> } finally {
>> >>> session.close();
>> >>> }
>> >>> }
>> >>>
>> >>> Well, I looked in the error log, also looked in the container
>> >>> log(JBoss) and didn't find any of theses strings "Somebody ...".
>> >>> The conclusion is that nobody called close explicit on the session.
>> >>> I placed that on 3 systems and over the weekend I got on all this
>> >>> problem. One common thing between the systems is that are all
>> >>> loaded(are test machines) and on all everything start to get
>> >>> "Session close" after I got this exception(see bellow).
>> >>>
>> >>> I don't know why we got java.io.InterruptedIOException:, it could be
>> >>> possible because of me :). We interrupt the current thread(which
>> >>> consume the message) if didn't respond after 60 secs(some kind of
>> >>> watchdog) so it is possible to be because I call explicit
>> >>> Thread.interrupt().
>> >>>
>> >>> Anyway, I thinkg, this should affect the sessions state(the close
>> >>> field should not be turned false by any other piece of code, except
>> >>> close() function, right?) should not be affected by am interrupt
>> >>> exception in a consumer.
>> >>>
>> >>> Thats all I could get about this problem with session close, anyway
>> >>> I think I will create all the time the session, to avoid this
>> problem.
>> >>>
>> >>> Thanks.
>> >>>
>> >>>
>> >>> 2006-07-15 03:24:54,628 [AcitveMQ Connection Worker:
>> >>> vm://localhost#0] ERROR
>> >>> com.daxtechnologies.sams.manager.SamsManagerJMS - JMS Error
>> >>> javax.jms.JMSException: Interrupted.
>> >>> at
>> >>>
>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>
>> >>>
>> >>> Caused by: java.io.InterruptedIOException: Interrupted.
>> >>> at
>> >>>
>> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
>>
>> >>>
>> >>> ... 23 more
>> >>> 2006-07-15 03:24:54,805 [SAMS-Worker-queue.contact_type-3] ERROR
>> >>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue - Cannot
>> >>> consume message from queue queue 'Contact Queue
>> >>> <sy...@daxtechnologies.com>' javax.jms.JMSException:
>> Interrupted.
>> >>> at
>> >>>
>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1141)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:145)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>
>> >>>
>> >>> at
>> >>>
>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>
>> >>>
>> >>> Caused by: java.io.InterruptedIOException: Interrupted.
>> >>> at
>> >>>
>> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
>>
>> >>>
>> >>> at
>> >>>
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>
>> >>>
>> >>> ... 7 more
>> >>>
>> >>> Adrian Tarau wrote:
>> >>>> More about closed session :)
>> >>>>
>> >>>> Could be possible that the closing problem could occur because the
>> >>>> Session is not per Thread, even if it is accessed by only on thread
>> >>>> at the time(or it should be accessed, but sometime is not -
>> >>>> backport-concurent problems)?
>> >>>>
>> >>>> The code look like that :
>> >>>> class MyStorageQueue {
>> >>>> private Session session;
>> >>>> private Queue queue;
>> >>>> protected final Semaphore lock = new Semaphore(1, true);
>> >>>> ....
>> >>>> public Object consume() {
>> >>>> ....
>> >>>> }
>> >>>>
>> >>>> public void publish(Object object) {
>> >>>> ....
>> >>>> }
>> >>>> }
>> >>>>
>> >>>> and usage in different threads
>> >>>> MyStorageQueue queue = getNextQueue(...);
>> >>>> if (queue.lock.tryAcquire()) {
>> >>>> try {
>> >>>> Object value = consume(queue);
>> >>>> .....
>> >>>> } finally {
>> >>>> queue.lock.release();
>> >>>> }
>> >>>> }
>> >>>>
>> >>>> Anyway I created a wrapper over an ActiveMQ session, and dump the
>> >>>> stack trace to see who calls the close method.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Adrian Tarau wrote:
>> >>>>> Debugging remove is not a problem, the problem is that I need to
>> >>>>> start the application in debug mode and keep the IDE with a
>> >>>>> breakpoint for days until it happens.
>> >>>>>
>> >>>>> I think I will recompile the ActiveMQ and dump the thread stack
>> >>>>> trace :)
>> >>>>>
>> >>>>> Sanjiv Jivan wrote:
>> >>>>>> You can attach your debugger to the Java process on the remote
>> >>>>>> machine and
>> >>>>>> set the breakpoint on the session.close() call. Once the
>> >>>>>> breakpoint it hit,
>> >>>>>> you can examine the call stack in your debugger.
>> >>>>>>
>> >>>>>> Use the JPDA socket JVM args when starting your Java process. Eg
>> >>>>>> : -Xdebug
>> >>>>>> -Xnoagent
>> >>>>>>
>> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >>>>>>>
>> >>>>>>> That's great but this usually happens on the remote machine,
>> >>>>>>> after a few
>> >>>>>>> days :)
>> >>>>>>>
>> >>>>>>> James Strachan wrote:
>> >>>>>>> > Maybe try run your code in a debugger and set breakpoints
>> in the
>> >>>>>>> > ActiveMQSession class to see where & why the session gets
>> >>>>>>> closed? (The
>> >>>>>>> > code's pretty easy to follow, its a relatively simple class).
>> >>>>>>> >
>> >>>>>>> >
>> >>>>>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >>>>>>> >> James, do you want the sources or can you recommend me some
>> >>>>>>> actions? To
>> >>>>>>> >> create the session all the time, not to cache it?
>> >>>>>>> >>
>> >>>>>>> >> Adrian Tarau wrote:
>> >>>>>>> >> > Ok, so who close the session? :)
>> >>>>>>> >> >
>> >>>>>>> >> > James Strachan wrote:
>> >>>>>>> >> >> Sorry I forgot about that :)
>> >>>>>>> >> >>
>> >>>>>>> >> >> The only time a VM broker is shut down is explicitly via
>> >>>>>>> application
>> >>>>>>> >> >> code or a shutdown handler.
>> >>>>>>> >> >>
>> >>>>>>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >>>>>>> >> >>> I use vm connector so no connection problems should be
>> >>>>>>> involved,
>> >>>>>>> >> right?
>> >>>>>>> >> >>>
>> >>>>>>> >> >>> James Strachan wrote:
>> >>>>>>> >> >>> > BTW are you using auto-reconnect? It could be that the
>> >>>>>>> socket is
>> >>>>>>> >> >>> > terminated due to some network issue?
>> >>>>>>> >> >>> >
>> >>>>>>> >> >>> >
>> >>>>>>> >> >>>
>> >>>>>>> >>
>> >>>>>>>
>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>
>> >>>>>>>
>> >>>>>>> >>
>> >>>>>>> >> >>>
>> >>>>>>> >> >>> >
>> >>>>>>> >> >>> >
>> >>>>>>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com>
>> wrote:
>> >>>>>>> >> >>> >> I made a search for "close" in the source code and
>> >>>>>>> except from
>> >>>>>>> >> >>> produces,
>> >>>>>>> >> >>> >> consumers and inputstream and outputstream I don't
>> >>>>>>> close the
>> >>>>>>> >> >>> connection
>> >>>>>>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>> >> I can provide you(private - not on the mailing
>> list) the
>> >>>>>>> >> source code
>> >>>>>>> >> >>> >> because this is very annoying.
>> >>>>>>> >> >>> >> Thanks.
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>> >> James Strachan wrote:
>> >>>>>>> >> >>> >> > Apart from inactivity timeouts on the transport
>> >>>>>>> layer, we
>> >>>>>>> >> >>> generally
>> >>>>>>> >> >>> >> > don't close sessions. Are you sure nothing in your
>> >>>>>>> application
>> >>>>>>> >> >>> code is
>> >>>>>>> >> >>> >> > trying to close the session?
>> >>>>>>> >> >>> >> >
>> >>>>>>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com>
>> >>>>>>> wrote:
>> >>>>>>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0
>> >>>>>>> and 4.0.1.
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >> I use vm transport and create one session used to
>> >>>>>>> produce and
>> >>>>>>> >> >>> consume
>> >>>>>>> >> >>> >> >> messages. Everything works fine, days in a row,
>> >>>>>>> until it
>> >>>>>>> >> start to
>> >>>>>>> >> >>> >> throw
>> >>>>>>> >> >>> >> >> exception that "Session is closed". There are any
>> >>>>>>> watch
>> >>>>>>> >> dogs that
>> >>>>>>> >> >>> >> close
>> >>>>>>> >> >>> >> >> sessions after a while, based on some criteria?
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >> I couldn't find any rule, when or why it happens.
>> >>>>>>> >> >>> >> >> Should I create the session all the time - I
>> >>>>>>> understood is
>> >>>>>>> >> time
>> >>>>>>> >> >>> >> >> consuming and it should be safe to cache it.
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >> Thanks.
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is
>> >>>>>>> closed
>> >>>>>>> >> >>> >> >> at
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>>
>> >>>>>>> >>
>> >>>>>>>
>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
>> >>>>>>>
>> >>>>>>> :577)
>> >>>>>>> >>
>> >>>>>>> >> >>>
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >> at
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>>
>> >>>>>>> >>
>> >>>>>>>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
>> >>>>>>>
>> >>>>>>> :799)*
>> >>>>>>> >>
>> >>>>>>> >> >>>
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >>
>> >>>>>>> >> >>> >> >
>> >>>>>>> >> >>> >> >
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>> >>
>> >>>>>>> >> >>> >
>> >>>>>>> >> >>> >
>> >>>>>>> >> >>>
>> >>>>>>> >> >>>
>> >>>>>>> >> >>
>> >>>>>>> >> >>
>> >>>>>>> >> >
>> >>>>>>> >>
>> >>>>>>> >>
>> >>>>>>> >
>> >>>>>>> >
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>>
>
>
Re: Session closed after a while(random)
Posted by James Strachan <ja...@gmail.com>.
It sounds like for some reason your transport is being closed due to
some kind of network issue. Generally if your code is not doing it
then the only time a session is closed is if the transport fails with
a serious exception.
So I'd
* enable debugging logging to watch the networking code and look for
errors/reconnections
Does your application run in a single JVM? i.e. there is just 1 JVM
with all the code inside and no TCP is being used at all? If not it
sounds like networking is failing such as a socket or inactivity
timeout or something - so either change your failover: configuration
or disable the inactivity timeout
http://incubator.apache.org/activemq/configuring-wire-formats.html
On 7/18/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> Anybody, please :) I don't know how to continue with this issue ...
>
> Adrian Tarau wrote:
> > Any thoughts ???
> >
> > Adrian Tarau wrote:
> >> I think I found the cause???? :)
> >>
> >> Look at this stack trace(which seems to be the source of our
> >> problems, after this exceptions we got "Session close"), which at
> >> some moment in time I got it(see bellow - I will mark with bold the
> >> what's important). Look at the bold stack entry, in
> >> ActiveMQConnection.onException.
> >> Un unrecoverable error in transport close the sessions, consumers,
> >> listeners , etc but doesn't close the connection.
> >>
> >> My question is how can I avoid getting the "Session close" message?
> >> How can I test if the session is closed? It is this the right way to
> >> handle a transport error, cleaning up the connection?
> >>
> >> I cannot test if the session is closed(ActiveMQSession.closed field
> >> is private), eventually I can try to do something with the session
> >> and in case of failure, I will recreate the session. Is this the
> >> right way to do it?
> >>
> >> Thanks.
> >>
> >> /**
> >> * An unrecoverable exception has occured on the transport
> >> * @param error
> >> */
> >> public void onException(final IOException error) {
> >> onAsyncException(error);
> >> asyncConnectionThread.execute(new Runnable(){
> >> public void run() {
> >> *transportFailed(error);*
> >>
> >> ServiceSupport.dispose(ActiveMQConnection.this.transport);
> >> brokerInfoReceived.countDown();
> >> for (Iterator iter =
> >> transportListeners.iterator(); iter.hasNext();) {
> >> TransportListener listener = (TransportListener)
> >> iter.next();
> >> listener.onException(error);
> >> }
> >> }
> >> });
> >> }
> >>
> >> and then transportFailed
> >>
> >> protected void transportFailed(IOException error){
> >> transportFailed.set(true);
> >> if (firstFailureError == null) {
> >> firstFailureError = error;
> >> }
> >> if (!closed.get() && !closing.get()) {
> >> try{
> >> *cleanup();*
> >> }catch(JMSException e){
> >> log.warn("Cleanup failed",e);
> >> }
> >> }
> >> }
> >>
> >> and then cleanup
> >>
> >> public void cleanup() throws JMSException {
> >> if( advisoryConsumer!=null ) {
> >> advisoryConsumer.dispose();
> >> advisoryConsumer=null;
> >> }
> >> for (Iterator i = this.sessions.iterator(); i.hasNext();) {
> >> *ActiveMQSession s = (ActiveMQSession) i.next();
> >> s.dispose();*
> >> }
> >> for (Iterator i = this.connectionConsumers.iterator();
> >> i.hasNext();) {
> >> ActiveMQConnectionConsumer c =
> >> (ActiveMQConnectionConsumer) i.next();
> >> c.dispose();
> >> }
> >> for (Iterator i = this.inputStreams.iterator(); i.hasNext();) {
> >> ActiveMQInputStream c = (ActiveMQInputStream) i.next();
> >> c.dispose();
> >> }
> >> for (Iterator i = this.outputStreams.iterator(); i.hasNext();) {
> >> ActiveMQOutputStream c = (ActiveMQOutputStream) i.next();
> >> c.dispose();
> >> }
> >>
> >> if(isConnectionInfoSentToBroker){
> >> if(!transportFailed.get() && !closing.get()){
> >> asyncSendPacket(info.createRemoveCommand());
> >> }
> >> isConnectionInfoSentToBroker=false;
> >> } if( userSpecifiedClientID ) {
> >> info.setClientId(null);
> >> userSpecifiedClientID=false;
> >> }
> >> clientIDSet = false;
> >>
> >> started.set(false);
> >> }
> >>
> >> *Stack trace*
> >>
> >> at
> >> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
> >>
> >> at
> >> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
> >>
> >> *at
> >> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)*
> >>
> >> at
> >> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
> >>
> >> at
> >> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
> >>
> >> at
> >> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
> >>
> >> at
> >> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
> >>
> >> at
> >> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> >> at
> >> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
> >>
> >> at
> >> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
> >>
> >> at
> >> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
> >>
> >> at
> >> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
> >>
> >> at
> >> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
> >>
> >> at
> >> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
> >>
> >> at
> >> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> >> at
> >> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
> >>
> >> at
> >> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
> >>
> >> at
> >> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
> >>
> >> at
> >> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
> >>
> >> at
> >> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
> >>
> >> at
> >> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
> >>
> >> at
> >> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
> >>
> >> at
> >> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
> >>
> >> at
> >> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
> >>
> >> at
> >> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
> >>
> >> at
> >> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
> >>
> >> at
> >> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
> >>
> >> at
> >> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
> >>
> >> at
> >> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
> >>
> >> Caused by: java.io.InterruptedIOException: Interrupted.
> >> at
> >> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
> >> at
> >> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
> >>
> >>
> >> Adrian Tarau wrote:
> >>> Even more :)
> >>>
> >>> As I told you I created a a Session wrapper over the ActiveMQ
> >>> session in order to catch the close call.
> >>>
> >>> you can see down bellow the close method :
> >>>
> >>> public void close() throws JMSException {
> >>> try {
> >>> IllegalAccessError illegalAccessError = new
> >>> IllegalAccessError("I don't want to close");
> >>> StringWriter sw = new StringWriter();
> >>> illegalAccessError.printStackTrace(new PrintWriter(sw));
> >>> LOG.error("Somebody closed the session, let's see
> >>> who\n\n" + sw.toString());
> >>> System.out.println("Somebody closed the session, let's
> >>> see who\n\n" + sw.toString());
> >>> } finally {
> >>> session.close();
> >>> }
> >>> }
> >>>
> >>> Well, I looked in the error log, also looked in the container
> >>> log(JBoss) and didn't find any of theses strings "Somebody ...".
> >>> The conclusion is that nobody called close explicit on the session.
> >>> I placed that on 3 systems and over the weekend I got on all this
> >>> problem. One common thing between the systems is that are all
> >>> loaded(are test machines) and on all everything start to get
> >>> "Session close" after I got this exception(see bellow).
> >>>
> >>> I don't know why we got java.io.InterruptedIOException:, it could be
> >>> possible because of me :). We interrupt the current thread(which
> >>> consume the message) if didn't respond after 60 secs(some kind of
> >>> watchdog) so it is possible to be because I call explicit
> >>> Thread.interrupt().
> >>>
> >>> Anyway, I thinkg, this should affect the sessions state(the close
> >>> field should not be turned false by any other piece of code, except
> >>> close() function, right?) should not be affected by am interrupt
> >>> exception in a consumer.
> >>>
> >>> Thats all I could get about this problem with session close, anyway
> >>> I think I will create all the time the session, to avoid this problem.
> >>>
> >>> Thanks.
> >>>
> >>>
> >>> 2006-07-15 03:24:54,628 [AcitveMQ Connection Worker:
> >>> vm://localhost#0] ERROR
> >>> com.daxtechnologies.sams.manager.SamsManagerJMS - JMS Error
> >>> javax.jms.JMSException: Interrupted.
> >>> at
> >>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)
> >>>
> >>> at
> >>> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
> >>>
> >>> at
> >>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
> >>>
> >>> at
> >>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> >>>
> >>> at
> >>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
> >>>
> >>> at
> >>> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
> >>>
> >>> at
> >>> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
> >>>
> >>> at
> >>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
> >>>
> >>> at
> >>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> >>>
> >>> at
> >>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
> >>>
> >>> Caused by: java.io.InterruptedIOException: Interrupted.
> >>> at
> >>> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
> >>>
> >>> ... 23 more
> >>> 2006-07-15 03:24:54,805 [SAMS-Worker-queue.contact_type-3] ERROR
> >>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue - Cannot
> >>> consume message from queue queue 'Contact Queue
> >>> <sy...@daxtechnologies.com>' javax.jms.JMSException: Interrupted.
> >>> at
> >>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1141)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:145)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
> >>>
> >>> at
> >>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
> >>>
> >>> Caused by: java.io.InterruptedIOException: Interrupted.
> >>> at
> >>> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
> >>>
> >>> at
> >>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
> >>>
> >>> at
> >>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
> >>>
> >>> ... 7 more
> >>>
> >>> Adrian Tarau wrote:
> >>>> More about closed session :)
> >>>>
> >>>> Could be possible that the closing problem could occur because the
> >>>> Session is not per Thread, even if it is accessed by only on thread
> >>>> at the time(or it should be accessed, but sometime is not -
> >>>> backport-concurent problems)?
> >>>>
> >>>> The code look like that :
> >>>> class MyStorageQueue {
> >>>> private Session session;
> >>>> private Queue queue;
> >>>> protected final Semaphore lock = new Semaphore(1, true);
> >>>> ....
> >>>> public Object consume() {
> >>>> ....
> >>>> }
> >>>>
> >>>> public void publish(Object object) {
> >>>> ....
> >>>> }
> >>>> }
> >>>>
> >>>> and usage in different threads
> >>>> MyStorageQueue queue = getNextQueue(...);
> >>>> if (queue.lock.tryAcquire()) {
> >>>> try {
> >>>> Object value = consume(queue);
> >>>> .....
> >>>> } finally {
> >>>> queue.lock.release();
> >>>> }
> >>>> }
> >>>>
> >>>> Anyway I created a wrapper over an ActiveMQ session, and dump the
> >>>> stack trace to see who calls the close method.
> >>>>
> >>>>
> >>>>
> >>>> Adrian Tarau wrote:
> >>>>> Debugging remove is not a problem, the problem is that I need to
> >>>>> start the application in debug mode and keep the IDE with a
> >>>>> breakpoint for days until it happens.
> >>>>>
> >>>>> I think I will recompile the ActiveMQ and dump the thread stack
> >>>>> trace :)
> >>>>>
> >>>>> Sanjiv Jivan wrote:
> >>>>>> You can attach your debugger to the Java process on the remote
> >>>>>> machine and
> >>>>>> set the breakpoint on the session.close() call. Once the
> >>>>>> breakpoint it hit,
> >>>>>> you can examine the call stack in your debugger.
> >>>>>>
> >>>>>> Use the JPDA socket JVM args when starting your Java process. Eg
> >>>>>> : -Xdebug
> >>>>>> -Xnoagent
> >>>>>> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >>>>>>>
> >>>>>>> That's great but this usually happens on the remote machine,
> >>>>>>> after a few
> >>>>>>> days :)
> >>>>>>>
> >>>>>>> James Strachan wrote:
> >>>>>>> > Maybe try run your code in a debugger and set breakpoints in the
> >>>>>>> > ActiveMQSession class to see where & why the session gets
> >>>>>>> closed? (The
> >>>>>>> > code's pretty easy to follow, its a relatively simple class).
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >>>>>>> >> James, do you want the sources or can you recommend me some
> >>>>>>> actions? To
> >>>>>>> >> create the session all the time, not to cache it?
> >>>>>>> >>
> >>>>>>> >> Adrian Tarau wrote:
> >>>>>>> >> > Ok, so who close the session? :)
> >>>>>>> >> >
> >>>>>>> >> > James Strachan wrote:
> >>>>>>> >> >> Sorry I forgot about that :)
> >>>>>>> >> >>
> >>>>>>> >> >> The only time a VM broker is shut down is explicitly via
> >>>>>>> application
> >>>>>>> >> >> code or a shutdown handler.
> >>>>>>> >> >>
> >>>>>>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >>>>>>> >> >>> I use vm connector so no connection problems should be
> >>>>>>> involved,
> >>>>>>> >> right?
> >>>>>>> >> >>>
> >>>>>>> >> >>> James Strachan wrote:
> >>>>>>> >> >>> > BTW are you using auto-reconnect? It could be that the
> >>>>>>> socket is
> >>>>>>> >> >>> > terminated due to some network issue?
> >>>>>>> >> >>> >
> >>>>>>> >> >>> >
> >>>>>>> >> >>>
> >>>>>>> >>
> >>>>>>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
> >>>>>>>
> >>>>>>> >>
> >>>>>>> >> >>>
> >>>>>>> >> >>> >
> >>>>>>> >> >>> >
> >>>>>>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >>>>>>> >> >>> >> I made a search for "close" in the source code and
> >>>>>>> except from
> >>>>>>> >> >>> produces,
> >>>>>>> >> >>> >> consumers and inputstream and outputstream I don't
> >>>>>>> close the
> >>>>>>> >> >>> connection
> >>>>>>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
> >>>>>>> >> >>> >>
> >>>>>>> >> >>> >> I can provide you(private - not on the mailing list) the
> >>>>>>> >> source code
> >>>>>>> >> >>> >> because this is very annoying.
> >>>>>>> >> >>> >> Thanks.
> >>>>>>> >> >>> >>
> >>>>>>> >> >>> >> James Strachan wrote:
> >>>>>>> >> >>> >> > Apart from inactivity timeouts on the transport
> >>>>>>> layer, we
> >>>>>>> >> >>> generally
> >>>>>>> >> >>> >> > don't close sessions. Are you sure nothing in your
> >>>>>>> application
> >>>>>>> >> >>> code is
> >>>>>>> >> >>> >> > trying to close the session?
> >>>>>>> >> >>> >> >
> >>>>>>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com>
> >>>>>>> wrote:
> >>>>>>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0
> >>>>>>> and 4.0.1.
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >> I use vm transport and create one session used to
> >>>>>>> produce and
> >>>>>>> >> >>> consume
> >>>>>>> >> >>> >> >> messages. Everything works fine, days in a row,
> >>>>>>> until it
> >>>>>>> >> start to
> >>>>>>> >> >>> >> throw
> >>>>>>> >> >>> >> >> exception that "Session is closed". There are any
> >>>>>>> watch
> >>>>>>> >> dogs that
> >>>>>>> >> >>> >> close
> >>>>>>> >> >>> >> >> sessions after a while, based on some criteria?
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >> I couldn't find any rule, when or why it happens.
> >>>>>>> >> >>> >> >> Should I create the session all the time - I
> >>>>>>> understood is
> >>>>>>> >> time
> >>>>>>> >> >>> >> >> consuming and it should be safe to cache it.
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >> Thanks.
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is
> >>>>>>> closed
> >>>>>>> >> >>> >> >> at
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >>
> >>>>>>> >> >>>
> >>>>>>> >>
> >>>>>>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
> >>>>>>>
> >>>>>>> :577)
> >>>>>>> >>
> >>>>>>> >> >>>
> >>>>>>> >> >>> >>
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >> at
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >>
> >>>>>>> >> >>>
> >>>>>>> >>
> >>>>>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
> >>>>>>>
> >>>>>>> :799)*
> >>>>>>> >>
> >>>>>>> >> >>>
> >>>>>>> >> >>> >>
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >>
> >>>>>>> >> >>> >> >
> >>>>>>> >> >>> >> >
> >>>>>>> >> >>> >>
> >>>>>>> >> >>> >>
> >>>>>>> >> >>> >
> >>>>>>> >> >>> >
> >>>>>>> >> >>>
> >>>>>>> >> >>>
> >>>>>>> >> >>
> >>>>>>> >> >>
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >
> >>>>>>> >
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
Anybody, please :) I don't know how to continue with this issue ...
Adrian Tarau wrote:
> Any thoughts ???
>
> Adrian Tarau wrote:
>> I think I found the cause???? :)
>>
>> Look at this stack trace(which seems to be the source of our
>> problems, after this exceptions we got "Session close"), which at
>> some moment in time I got it(see bellow - I will mark with bold the
>> what's important). Look at the bold stack entry, in
>> ActiveMQConnection.onException.
>> Un unrecoverable error in transport close the sessions, consumers,
>> listeners , etc but doesn't close the connection.
>>
>> My question is how can I avoid getting the "Session close" message?
>> How can I test if the session is closed? It is this the right way to
>> handle a transport error, cleaning up the connection?
>>
>> I cannot test if the session is closed(ActiveMQSession.closed field
>> is private), eventually I can try to do something with the session
>> and in case of failure, I will recreate the session. Is this the
>> right way to do it?
>>
>> Thanks.
>>
>> /**
>> * An unrecoverable exception has occured on the transport
>> * @param error
>> */
>> public void onException(final IOException error) {
>> onAsyncException(error);
>> asyncConnectionThread.execute(new Runnable(){
>> public void run() {
>> *transportFailed(error);*
>>
>> ServiceSupport.dispose(ActiveMQConnection.this.transport);
>> brokerInfoReceived.countDown();
>> for (Iterator iter =
>> transportListeners.iterator(); iter.hasNext();) {
>> TransportListener listener = (TransportListener)
>> iter.next();
>> listener.onException(error);
>> }
>> }
>> });
>> }
>>
>> and then transportFailed
>>
>> protected void transportFailed(IOException error){
>> transportFailed.set(true);
>> if (firstFailureError == null) {
>> firstFailureError = error;
>> }
>> if (!closed.get() && !closing.get()) {
>> try{
>> *cleanup();*
>> }catch(JMSException e){
>> log.warn("Cleanup failed",e);
>> }
>> }
>> }
>>
>> and then cleanup
>>
>> public void cleanup() throws JMSException {
>> if( advisoryConsumer!=null ) {
>> advisoryConsumer.dispose();
>> advisoryConsumer=null;
>> }
>> for (Iterator i = this.sessions.iterator(); i.hasNext();) {
>> *ActiveMQSession s = (ActiveMQSession) i.next();
>> s.dispose();*
>> }
>> for (Iterator i = this.connectionConsumers.iterator();
>> i.hasNext();) {
>> ActiveMQConnectionConsumer c =
>> (ActiveMQConnectionConsumer) i.next();
>> c.dispose();
>> }
>> for (Iterator i = this.inputStreams.iterator(); i.hasNext();) {
>> ActiveMQInputStream c = (ActiveMQInputStream) i.next();
>> c.dispose();
>> }
>> for (Iterator i = this.outputStreams.iterator(); i.hasNext();) {
>> ActiveMQOutputStream c = (ActiveMQOutputStream) i.next();
>> c.dispose();
>> }
>>
>> if(isConnectionInfoSentToBroker){
>> if(!transportFailed.get() && !closing.get()){
>> asyncSendPacket(info.createRemoveCommand());
>> }
>> isConnectionInfoSentToBroker=false;
>> } if( userSpecifiedClientID ) {
>> info.setClientId(null);
>> userSpecifiedClientID=false;
>> }
>> clientIDSet = false;
>>
>> started.set(false);
>> }
>>
>> *Stack trace*
>>
>> at
>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
>>
>> at
>> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
>>
>> *at
>> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)*
>>
>> at
>> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
>>
>> at
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> at
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> at
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
>>
>> at
>> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
>>
>> at
>> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
>>
>> at
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> at
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> at
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
>>
>> at
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>
>> at
>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>
>> at
>> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
>>
>> at
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
>>
>> at
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
>>
>> at
>> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
>>
>> at
>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>
>> Caused by: java.io.InterruptedIOException: Interrupted.
>> at
>> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
>>
>>
>> Adrian Tarau wrote:
>>> Even more :)
>>>
>>> As I told you I created a a Session wrapper over the ActiveMQ
>>> session in order to catch the close call.
>>>
>>> you can see down bellow the close method :
>>>
>>> public void close() throws JMSException {
>>> try {
>>> IllegalAccessError illegalAccessError = new
>>> IllegalAccessError("I don't want to close");
>>> StringWriter sw = new StringWriter();
>>> illegalAccessError.printStackTrace(new PrintWriter(sw));
>>> LOG.error("Somebody closed the session, let's see
>>> who\n\n" + sw.toString());
>>> System.out.println("Somebody closed the session, let's
>>> see who\n\n" + sw.toString());
>>> } finally {
>>> session.close();
>>> }
>>> }
>>>
>>> Well, I looked in the error log, also looked in the container
>>> log(JBoss) and didn't find any of theses strings "Somebody ...".
>>> The conclusion is that nobody called close explicit on the session.
>>> I placed that on 3 systems and over the weekend I got on all this
>>> problem. One common thing between the systems is that are all
>>> loaded(are test machines) and on all everything start to get
>>> "Session close" after I got this exception(see bellow).
>>>
>>> I don't know why we got java.io.InterruptedIOException:, it could be
>>> possible because of me :). We interrupt the current thread(which
>>> consume the message) if didn't respond after 60 secs(some kind of
>>> watchdog) so it is possible to be because I call explicit
>>> Thread.interrupt().
>>>
>>> Anyway, I thinkg, this should affect the sessions state(the close
>>> field should not be turned false by any other piece of code, except
>>> close() function, right?) should not be affected by am interrupt
>>> exception in a consumer.
>>>
>>> Thats all I could get about this problem with session close, anyway
>>> I think I will create all the time the session, to avoid this problem.
>>>
>>> Thanks.
>>>
>>>
>>> 2006-07-15 03:24:54,628 [AcitveMQ Connection Worker:
>>> vm://localhost#0] ERROR
>>> com.daxtechnologies.sams.manager.SamsManagerJMS - JMS Error
>>> javax.jms.JMSException: Interrupted.
>>> at
>>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
>>>
>>> at
>>> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
>>>
>>> at
>>> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)
>>>
>>> at
>>> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
>>>
>>> at
>>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>>
>>> at
>>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>>>
>>> at
>>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
>>>
>>> at
>>> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
>>>
>>> at
>>> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
>>>
>>> at
>>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>>
>>> at
>>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>>>
>>> at
>>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
>>>
>>> at
>>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>>
>>> at
>>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>>
>>> at
>>> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
>>>
>>> at
>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
>>>
>>> at
>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>>
>>> Caused by: java.io.InterruptedIOException: Interrupted.
>>> at
>>> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
>>>
>>> ... 23 more
>>> 2006-07-15 03:24:54,805 [SAMS-Worker-queue.contact_type-3] ERROR
>>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue - Cannot
>>> consume message from queue queue 'Contact Queue
>>> <sy...@daxtechnologies.com>' javax.jms.JMSException: Interrupted.
>>> at
>>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
>>>
>>> at
>>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1141)
>>>
>>> at
>>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>>
>>> at
>>> org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:145)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>>
>>> at
>>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>>
>>> Caused by: java.io.InterruptedIOException: Interrupted.
>>> at
>>> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
>>>
>>> at
>>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
>>>
>>> at
>>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>>
>>> ... 7 more
>>>
>>> Adrian Tarau wrote:
>>>> More about closed session :)
>>>>
>>>> Could be possible that the closing problem could occur because the
>>>> Session is not per Thread, even if it is accessed by only on thread
>>>> at the time(or it should be accessed, but sometime is not -
>>>> backport-concurent problems)?
>>>>
>>>> The code look like that :
>>>> class MyStorageQueue {
>>>> private Session session;
>>>> private Queue queue;
>>>> protected final Semaphore lock = new Semaphore(1, true);
>>>> ....
>>>> public Object consume() {
>>>> ....
>>>> }
>>>>
>>>> public void publish(Object object) {
>>>> ....
>>>> }
>>>> }
>>>>
>>>> and usage in different threads
>>>> MyStorageQueue queue = getNextQueue(...);
>>>> if (queue.lock.tryAcquire()) {
>>>> try {
>>>> Object value = consume(queue);
>>>> .....
>>>> } finally {
>>>> queue.lock.release();
>>>> }
>>>> }
>>>>
>>>> Anyway I created a wrapper over an ActiveMQ session, and dump the
>>>> stack trace to see who calls the close method.
>>>>
>>>>
>>>>
>>>> Adrian Tarau wrote:
>>>>> Debugging remove is not a problem, the problem is that I need to
>>>>> start the application in debug mode and keep the IDE with a
>>>>> breakpoint for days until it happens.
>>>>>
>>>>> I think I will recompile the ActiveMQ and dump the thread stack
>>>>> trace :)
>>>>>
>>>>> Sanjiv Jivan wrote:
>>>>>> You can attach your debugger to the Java process on the remote
>>>>>> machine and
>>>>>> set the breakpoint on the session.close() call. Once the
>>>>>> breakpoint it hit,
>>>>>> you can examine the call stack in your debugger.
>>>>>>
>>>>>> Use the JPDA socket JVM args when starting your Java process. Eg
>>>>>> : -Xdebug
>>>>>> -Xnoagent
>>>>>> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>>>
>>>>>>> That's great but this usually happens on the remote machine,
>>>>>>> after a few
>>>>>>> days :)
>>>>>>>
>>>>>>> James Strachan wrote:
>>>>>>> > Maybe try run your code in a debugger and set breakpoints in the
>>>>>>> > ActiveMQSession class to see where & why the session gets
>>>>>>> closed? (The
>>>>>>> > code's pretty easy to follow, its a relatively simple class).
>>>>>>> >
>>>>>>> >
>>>>>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>>> >> James, do you want the sources or can you recommend me some
>>>>>>> actions? To
>>>>>>> >> create the session all the time, not to cache it?
>>>>>>> >>
>>>>>>> >> Adrian Tarau wrote:
>>>>>>> >> > Ok, so who close the session? :)
>>>>>>> >> >
>>>>>>> >> > James Strachan wrote:
>>>>>>> >> >> Sorry I forgot about that :)
>>>>>>> >> >>
>>>>>>> >> >> The only time a VM broker is shut down is explicitly via
>>>>>>> application
>>>>>>> >> >> code or a shutdown handler.
>>>>>>> >> >>
>>>>>>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>>> >> >>> I use vm connector so no connection problems should be
>>>>>>> involved,
>>>>>>> >> right?
>>>>>>> >> >>>
>>>>>>> >> >>> James Strachan wrote:
>>>>>>> >> >>> > BTW are you using auto-reconnect? It could be that the
>>>>>>> socket is
>>>>>>> >> >>> > terminated due to some network issue?
>>>>>>> >> >>> >
>>>>>>> >> >>> >
>>>>>>> >> >>>
>>>>>>> >>
>>>>>>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>>>>>>
>>>>>>> >>
>>>>>>> >> >>>
>>>>>>> >> >>> >
>>>>>>> >> >>> >
>>>>>>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>>> >> >>> >> I made a search for "close" in the source code and
>>>>>>> except from
>>>>>>> >> >>> produces,
>>>>>>> >> >>> >> consumers and inputstream and outputstream I don't
>>>>>>> close the
>>>>>>> >> >>> connection
>>>>>>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
>>>>>>> >> >>> >>
>>>>>>> >> >>> >> I can provide you(private - not on the mailing list) the
>>>>>>> >> source code
>>>>>>> >> >>> >> because this is very annoying.
>>>>>>> >> >>> >> Thanks.
>>>>>>> >> >>> >>
>>>>>>> >> >>> >> James Strachan wrote:
>>>>>>> >> >>> >> > Apart from inactivity timeouts on the transport
>>>>>>> layer, we
>>>>>>> >> >>> generally
>>>>>>> >> >>> >> > don't close sessions. Are you sure nothing in your
>>>>>>> application
>>>>>>> >> >>> code is
>>>>>>> >> >>> >> > trying to close the session?
>>>>>>> >> >>> >> >
>>>>>>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com>
>>>>>>> wrote:
>>>>>>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0
>>>>>>> and 4.0.1.
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >> I use vm transport and create one session used to
>>>>>>> produce and
>>>>>>> >> >>> consume
>>>>>>> >> >>> >> >> messages. Everything works fine, days in a row,
>>>>>>> until it
>>>>>>> >> start to
>>>>>>> >> >>> >> throw
>>>>>>> >> >>> >> >> exception that "Session is closed". There are any
>>>>>>> watch
>>>>>>> >> dogs that
>>>>>>> >> >>> >> close
>>>>>>> >> >>> >> >> sessions after a while, based on some criteria?
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >> I couldn't find any rule, when or why it happens.
>>>>>>> >> >>> >> >> Should I create the session all the time - I
>>>>>>> understood is
>>>>>>> >> time
>>>>>>> >> >>> >> >> consuming and it should be safe to cache it.
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >> Thanks.
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is
>>>>>>> closed
>>>>>>> >> >>> >> >> at
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >>
>>>>>>> >> >>>
>>>>>>> >>
>>>>>>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
>>>>>>>
>>>>>>> :577)
>>>>>>> >>
>>>>>>> >> >>>
>>>>>>> >> >>> >>
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >> at
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >>
>>>>>>> >> >>>
>>>>>>> >>
>>>>>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
>>>>>>>
>>>>>>> :799)*
>>>>>>> >>
>>>>>>> >> >>>
>>>>>>> >> >>> >>
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >>
>>>>>>> >> >>> >> >
>>>>>>> >> >>> >> >
>>>>>>> >> >>> >>
>>>>>>> >> >>> >>
>>>>>>> >> >>> >
>>>>>>> >> >>> >
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
Any thoughts ???
Adrian Tarau wrote:
> I think I found the cause???? :)
>
> Look at this stack trace(which seems to be the source of our problems,
> after this exceptions we got "Session close"), which at some moment in
> time I got it(see bellow - I will mark with bold the what's
> important). Look at the bold stack entry, in
> ActiveMQConnection.onException.
> Un unrecoverable error in transport close the sessions, consumers,
> listeners , etc but doesn't close the connection.
>
> My question is how can I avoid getting the "Session close" message?
> How can I test if the session is closed? It is this the right way to
> handle a transport error, cleaning up the connection?
>
> I cannot test if the session is closed(ActiveMQSession.closed field is
> private), eventually I can try to do something with the session and in
> case of failure, I will recreate the session. Is this the right way to
> do it?
>
> Thanks.
>
> /**
> * An unrecoverable exception has occured on the transport
> * @param error
> */
> public void onException(final IOException error) {
> onAsyncException(error);
> asyncConnectionThread.execute(new Runnable(){
> public void run() {
> *transportFailed(error);*
> ServiceSupport.dispose(ActiveMQConnection.this.transport);
> brokerInfoReceived.countDown();
> for (Iterator iter =
> transportListeners.iterator(); iter.hasNext();) {
> TransportListener listener = (TransportListener)
> iter.next();
> listener.onException(error);
> }
> }
> });
> }
>
> and then transportFailed
>
> protected void transportFailed(IOException error){
> transportFailed.set(true);
> if (firstFailureError == null) {
> firstFailureError = error;
> }
> if (!closed.get() && !closing.get()) {
> try{
> *cleanup();*
> }catch(JMSException e){
> log.warn("Cleanup failed",e);
> }
> }
> }
>
> and then cleanup
>
> public void cleanup() throws JMSException {
> if( advisoryConsumer!=null ) {
> advisoryConsumer.dispose();
> advisoryConsumer=null;
> }
> for (Iterator i = this.sessions.iterator(); i.hasNext();) {
> *ActiveMQSession s = (ActiveMQSession) i.next();
> s.dispose();*
> }
> for (Iterator i = this.connectionConsumers.iterator();
> i.hasNext();) {
> ActiveMQConnectionConsumer c = (ActiveMQConnectionConsumer)
> i.next();
> c.dispose();
> }
> for (Iterator i = this.inputStreams.iterator(); i.hasNext();) {
> ActiveMQInputStream c = (ActiveMQInputStream) i.next();
> c.dispose();
> }
> for (Iterator i = this.outputStreams.iterator(); i.hasNext();) {
> ActiveMQOutputStream c = (ActiveMQOutputStream) i.next();
> c.dispose();
> }
>
> if(isConnectionInfoSentToBroker){
> if(!transportFailed.get() && !closing.get()){
> asyncSendPacket(info.createRemoveCommand());
> }
> isConnectionInfoSentToBroker=false;
> } if( userSpecifiedClientID ) {
> info.setClientId(null);
> userSpecifiedClientID=false;
> }
> clientIDSet = false;
>
> started.set(false);
> }
>
> *Stack trace*
>
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
>
> at
> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
>
> *at
> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)*
>
> at
> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
>
> at
> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>
> at
> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
>
> at
> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
>
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
>
> at
> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>
> at
> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
>
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>
> at
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>
> at
> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
>
> at
> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
>
> at
> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
>
> at
> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
>
> at
> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>
> Caused by: java.io.InterruptedIOException: Interrupted.
> at
> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
>
>
> Adrian Tarau wrote:
>> Even more :)
>>
>> As I told you I created a a Session wrapper over the ActiveMQ session
>> in order to catch the close call.
>>
>> you can see down bellow the close method :
>>
>> public void close() throws JMSException {
>> try {
>> IllegalAccessError illegalAccessError = new
>> IllegalAccessError("I don't want to close");
>> StringWriter sw = new StringWriter();
>> illegalAccessError.printStackTrace(new PrintWriter(sw));
>> LOG.error("Somebody closed the session, let's see who\n\n"
>> + sw.toString());
>> System.out.println("Somebody closed the session, let's see
>> who\n\n" + sw.toString());
>> } finally {
>> session.close();
>> }
>> }
>>
>> Well, I looked in the error log, also looked in the container
>> log(JBoss) and didn't find any of theses strings "Somebody ...". The
>> conclusion is that nobody called close explicit on the session.
>> I placed that on 3 systems and over the weekend I got on all this
>> problem. One common thing between the systems is that are all
>> loaded(are test machines) and on all everything start to get "Session
>> close" after I got this exception(see bellow).
>>
>> I don't know why we got java.io.InterruptedIOException:, it could be
>> possible because of me :). We interrupt the current thread(which
>> consume the message) if didn't respond after 60 secs(some kind of
>> watchdog) so it is possible to be because I call explicit
>> Thread.interrupt().
>>
>> Anyway, I thinkg, this should affect the sessions state(the close
>> field should not be turned false by any other piece of code, except
>> close() function, right?) should not be affected by am interrupt
>> exception in a consumer.
>>
>> Thats all I could get about this problem with session close, anyway I
>> think I will create all the time the session, to avoid this problem.
>>
>> Thanks.
>>
>>
>> 2006-07-15 03:24:54,628 [AcitveMQ Connection Worker:
>> vm://localhost#0] ERROR
>> com.daxtechnologies.sams.manager.SamsManagerJMS - JMS Error
>> javax.jms.JMSException: Interrupted.
>> at
>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
>>
>> at
>> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
>>
>> at
>> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)
>>
>> at
>> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
>>
>> at
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> at
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> at
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
>>
>> at
>> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
>>
>> at
>> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
>>
>> at
>> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>>
>> at
>> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
>> at
>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
>>
>> at
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>
>> at
>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>
>> at
>> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
>>
>> at
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
>>
>> at
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
>>
>> at
>> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
>>
>> at
>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>
>> Caused by: java.io.InterruptedIOException: Interrupted.
>> at
>> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
>> at
>> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
>>
>> ... 23 more
>> 2006-07-15 03:24:54,805 [SAMS-Worker-queue.contact_type-3] ERROR
>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue - Cannot
>> consume message from queue queue 'Contact Queue
>> <sy...@daxtechnologies.com>' javax.jms.JMSException: Interrupted.
>> at
>> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
>>
>> at
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1141)
>>
>> at
>> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>>
>> at
>> org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516)
>>
>> at
>> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:145)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>>
>> at
>> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>>
>> Caused by: java.io.InterruptedIOException: Interrupted.
>> at
>> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
>>
>> at
>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
>>
>> at
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>>
>> ... 7 more
>>
>> Adrian Tarau wrote:
>>> More about closed session :)
>>>
>>> Could be possible that the closing problem could occur because the
>>> Session is not per Thread, even if it is accessed by only on thread
>>> at the time(or it should be accessed, but sometime is not -
>>> backport-concurent problems)?
>>>
>>> The code look like that :
>>> class MyStorageQueue {
>>> private Session session;
>>> private Queue queue;
>>> protected final Semaphore lock = new Semaphore(1, true);
>>> ....
>>> public Object consume() {
>>> ....
>>> }
>>>
>>> public void publish(Object object) {
>>> ....
>>> }
>>> }
>>>
>>> and usage in different threads
>>> MyStorageQueue queue = getNextQueue(...);
>>> if (queue.lock.tryAcquire()) {
>>> try {
>>> Object value = consume(queue);
>>> .....
>>> } finally {
>>> queue.lock.release();
>>> }
>>> }
>>>
>>> Anyway I created a wrapper over an ActiveMQ session, and dump the
>>> stack trace to see who calls the close method.
>>>
>>>
>>>
>>> Adrian Tarau wrote:
>>>> Debugging remove is not a problem, the problem is that I need to
>>>> start the application in debug mode and keep the IDE with a
>>>> breakpoint for days until it happens.
>>>>
>>>> I think I will recompile the ActiveMQ and dump the thread stack
>>>> trace :)
>>>>
>>>> Sanjiv Jivan wrote:
>>>>> You can attach your debugger to the Java process on the remote
>>>>> machine and
>>>>> set the breakpoint on the session.close() call. Once the
>>>>> breakpoint it hit,
>>>>> you can examine the call stack in your debugger.
>>>>>
>>>>> Use the JPDA socket JVM args when starting your Java process. Eg
>>>>> : -Xdebug
>>>>> -Xnoagent
>>>>> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>>>>>
>>>>>
>>>>>
>>>>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>>
>>>>>> That's great but this usually happens on the remote machine,
>>>>>> after a few
>>>>>> days :)
>>>>>>
>>>>>> James Strachan wrote:
>>>>>> > Maybe try run your code in a debugger and set breakpoints in the
>>>>>> > ActiveMQSession class to see where & why the session gets
>>>>>> closed? (The
>>>>>> > code's pretty easy to follow, its a relatively simple class).
>>>>>> >
>>>>>> >
>>>>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>> >> James, do you want the sources or can you recommend me some
>>>>>> actions? To
>>>>>> >> create the session all the time, not to cache it?
>>>>>> >>
>>>>>> >> Adrian Tarau wrote:
>>>>>> >> > Ok, so who close the session? :)
>>>>>> >> >
>>>>>> >> > James Strachan wrote:
>>>>>> >> >> Sorry I forgot about that :)
>>>>>> >> >>
>>>>>> >> >> The only time a VM broker is shut down is explicitly via
>>>>>> application
>>>>>> >> >> code or a shutdown handler.
>>>>>> >> >>
>>>>>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>> >> >>> I use vm connector so no connection problems should be
>>>>>> involved,
>>>>>> >> right?
>>>>>> >> >>>
>>>>>> >> >>> James Strachan wrote:
>>>>>> >> >>> > BTW are you using auto-reconnect? It could be that the
>>>>>> socket is
>>>>>> >> >>> > terminated due to some network issue?
>>>>>> >> >>> >
>>>>>> >> >>> >
>>>>>> >> >>>
>>>>>> >>
>>>>>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>>>>>
>>>>>> >>
>>>>>> >> >>>
>>>>>> >> >>> >
>>>>>> >> >>> >
>>>>>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>> >> >>> >> I made a search for "close" in the source code and
>>>>>> except from
>>>>>> >> >>> produces,
>>>>>> >> >>> >> consumers and inputstream and outputstream I don't
>>>>>> close the
>>>>>> >> >>> connection
>>>>>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
>>>>>> >> >>> >>
>>>>>> >> >>> >> I can provide you(private - not on the mailing list) the
>>>>>> >> source code
>>>>>> >> >>> >> because this is very annoying.
>>>>>> >> >>> >> Thanks.
>>>>>> >> >>> >>
>>>>>> >> >>> >> James Strachan wrote:
>>>>>> >> >>> >> > Apart from inactivity timeouts on the transport
>>>>>> layer, we
>>>>>> >> >>> generally
>>>>>> >> >>> >> > don't close sessions. Are you sure nothing in your
>>>>>> application
>>>>>> >> >>> code is
>>>>>> >> >>> >> > trying to close the session?
>>>>>> >> >>> >> >
>>>>>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com>
>>>>>> wrote:
>>>>>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0
>>>>>> and 4.0.1.
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >> I use vm transport and create one session used to
>>>>>> produce and
>>>>>> >> >>> consume
>>>>>> >> >>> >> >> messages. Everything works fine, days in a row,
>>>>>> until it
>>>>>> >> start to
>>>>>> >> >>> >> throw
>>>>>> >> >>> >> >> exception that "Session is closed". There are any watch
>>>>>> >> dogs that
>>>>>> >> >>> >> close
>>>>>> >> >>> >> >> sessions after a while, based on some criteria?
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >> I couldn't find any rule, when or why it happens.
>>>>>> >> >>> >> >> Should I create the session all the time - I
>>>>>> understood is
>>>>>> >> time
>>>>>> >> >>> >> >> consuming and it should be safe to cache it.
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >> Thanks.
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
>>>>>> >> >>> >> >> at
>>>>>> >> >>> >> >>
>>>>>> >> >>> >>
>>>>>> >> >>>
>>>>>> >>
>>>>>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
>>>>>> :577)
>>>>>> >>
>>>>>> >> >>>
>>>>>> >> >>> >>
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >> at
>>>>>> >> >>> >> >>
>>>>>> >> >>> >>
>>>>>> >> >>>
>>>>>> >>
>>>>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
>>>>>>
>>>>>> :799)*
>>>>>> >>
>>>>>> >> >>>
>>>>>> >> >>> >>
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >>
>>>>>> >> >>> >> >
>>>>>> >> >>> >> >
>>>>>> >> >>> >>
>>>>>> >> >>> >>
>>>>>> >> >>> >
>>>>>> >> >>> >
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
I think I found the cause???? :)
Look at this stack trace(which seems to be the source of our problems,
after this exceptions we got "Session close"), which at some moment in
time I got it(see bellow - I will mark with bold the what's important).
Look at the bold stack entry, in ActiveMQConnection.onException.
Un unrecoverable error in transport close the sessions, consumers,
listeners , etc but doesn't close the connection.
My question is how can I avoid getting the "Session close" message? How
can I test if the session is closed? It is this the right way to handle
a transport error, cleaning up the connection?
I cannot test if the session is closed(ActiveMQSession.closed field is
private), eventually I can try to do something with the session and in
case of failure, I will recreate the session. Is this the right way to
do it?
Thanks.
/**
* An unrecoverable exception has occured on the transport
* @param error
*/
public void onException(final IOException error) {
onAsyncException(error);
asyncConnectionThread.execute(new Runnable(){
public void run() {
*transportFailed(error);*
ServiceSupport.dispose(ActiveMQConnection.this.transport);
brokerInfoReceived.countDown();
for (Iterator iter = transportListeners.iterator();
iter.hasNext();) {
TransportListener listener = (TransportListener)
iter.next();
listener.onException(error);
}
}
});
}
and then transportFailed
protected void transportFailed(IOException error){
transportFailed.set(true);
if (firstFailureError == null) {
firstFailureError = error;
}
if (!closed.get() && !closing.get()) {
try{
*cleanup();*
}catch(JMSException e){
log.warn("Cleanup failed",e);
}
}
}
and then cleanup
public void cleanup() throws JMSException {
if( advisoryConsumer!=null ) {
advisoryConsumer.dispose();
advisoryConsumer=null;
}
for (Iterator i = this.sessions.iterator(); i.hasNext();) {
*ActiveMQSession s = (ActiveMQSession) i.next();
s.dispose();*
}
for (Iterator i = this.connectionConsumers.iterator();
i.hasNext();) {
ActiveMQConnectionConsumer c = (ActiveMQConnectionConsumer)
i.next();
c.dispose();
}
for (Iterator i = this.inputStreams.iterator(); i.hasNext();) {
ActiveMQInputStream c = (ActiveMQInputStream) i.next();
c.dispose();
}
for (Iterator i = this.outputStreams.iterator(); i.hasNext();) {
ActiveMQOutputStream c = (ActiveMQOutputStream) i.next();
c.dispose();
}
if(isConnectionInfoSentToBroker){
if(!transportFailed.get() && !closing.get()){
asyncSendPacket(info.createRemoveCommand());
}
isConnectionInfoSentToBroker=false;
}
if( userSpecifiedClientID ) {
info.setClientId(null);
userSpecifiedClientID=false;
}
clientIDSet = false;
started.set(false);
}
*Stack trace*
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
at
org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
*at
org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)*
at
org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
at
org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
at
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
at
org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
at
com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
at
com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
at
com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
Caused by: java.io.InterruptedIOException: Interrupted.
at
org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
Adrian Tarau wrote:
> Even more :)
>
> As I told you I created a a Session wrapper over the ActiveMQ session
> in order to catch the close call.
>
> you can see down bellow the close method :
>
> public void close() throws JMSException {
> try {
> IllegalAccessError illegalAccessError = new
> IllegalAccessError("I don't want to close");
> StringWriter sw = new StringWriter();
> illegalAccessError.printStackTrace(new PrintWriter(sw));
> LOG.error("Somebody closed the session, let's see who\n\n"
> + sw.toString());
> System.out.println("Somebody closed the session, let's see
> who\n\n" + sw.toString());
> } finally {
> session.close();
> }
> }
>
> Well, I looked in the error log, also looked in the container
> log(JBoss) and didn't find any of theses strings "Somebody ...". The
> conclusion is that nobody called close explicit on the session.
> I placed that on 3 systems and over the weekend I got on all this
> problem. One common thing between the systems is that are all
> loaded(are test machines) and on all everything start to get "Session
> close" after I got this exception(see bellow).
>
> I don't know why we got java.io.InterruptedIOException:, it could be
> possible because of me :). We interrupt the current thread(which
> consume the message) if didn't respond after 60 secs(some kind of
> watchdog) so it is possible to be because I call explicit
> Thread.interrupt().
>
> Anyway, I thinkg, this should affect the sessions state(the close
> field should not be turned false by any other piece of code, except
> close() function, right?) should not be affected by am interrupt
> exception in a consumer.
>
> Thats all I could get about this problem with session close, anyway I
> think I will create all the time the session, to avoid this problem.
>
> Thanks.
>
>
> 2006-07-15 03:24:54,628 [AcitveMQ Connection Worker: vm://localhost#0]
> ERROR com.daxtechnologies.sams.manager.SamsManagerJMS - JMS Error
> javax.jms.JMSException: Interrupted.
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
>
> at
> org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
>
> at
> org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)
>
> at
> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
>
> at
> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>
> at
> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
>
> at
> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
>
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
>
> at
> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
>
> at
> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
> at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
>
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>
> at
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>
> at
> org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
>
> at
> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
>
> at
> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
>
> at
> com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
>
> at
> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>
> Caused by: java.io.InterruptedIOException: Interrupted.
> at
> org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
>
> ... 23 more
> 2006-07-15 03:24:54,805 [SAMS-Worker-queue.contact_type-3] ERROR
> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue - Cannot
> consume message from queue queue 'Contact Queue
> <sy...@daxtechnologies.com>' javax.jms.JMSException: Interrupted.
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
>
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1141)
>
> at
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
>
> at
> org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516)
>
> at
> com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:145)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
>
> at
> com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
>
> Caused by: java.io.InterruptedIOException: Interrupted.
> at
> org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
>
> at
> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
>
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
>
> ... 7 more
>
> Adrian Tarau wrote:
>> More about closed session :)
>>
>> Could be possible that the closing problem could occur because the
>> Session is not per Thread, even if it is accessed by only on thread
>> at the time(or it should be accessed, but sometime is not -
>> backport-concurent problems)?
>>
>> The code look like that :
>> class MyStorageQueue {
>> private Session session;
>> private Queue queue;
>> protected final Semaphore lock = new Semaphore(1, true);
>> ....
>> public Object consume() {
>> ....
>> }
>>
>> public void publish(Object object) {
>> ....
>> }
>> }
>>
>> and usage in different threads
>> MyStorageQueue queue = getNextQueue(...);
>> if (queue.lock.tryAcquire()) {
>> try {
>> Object value = consume(queue);
>> .....
>> } finally {
>> queue.lock.release();
>> }
>> }
>>
>> Anyway I created a wrapper over an ActiveMQ session, and dump the
>> stack trace to see who calls the close method.
>>
>>
>>
>> Adrian Tarau wrote:
>>> Debugging remove is not a problem, the problem is that I need to
>>> start the application in debug mode and keep the IDE with a
>>> breakpoint for days until it happens.
>>>
>>> I think I will recompile the ActiveMQ and dump the thread stack
>>> trace :)
>>>
>>> Sanjiv Jivan wrote:
>>>> You can attach your debugger to the Java process on the remote
>>>> machine and
>>>> set the breakpoint on the session.close() call. Once the breakpoint
>>>> it hit,
>>>> you can examine the call stack in your debugger.
>>>>
>>>> Use the JPDA socket JVM args when starting your Java process. Eg :
>>>> -Xdebug
>>>> -Xnoagent
>>>> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>>>>
>>>>
>>>>
>>>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>>
>>>>> That's great but this usually happens on the remote machine, after
>>>>> a few
>>>>> days :)
>>>>>
>>>>> James Strachan wrote:
>>>>> > Maybe try run your code in a debugger and set breakpoints in the
>>>>> > ActiveMQSession class to see where & why the session gets
>>>>> closed? (The
>>>>> > code's pretty easy to follow, its a relatively simple class).
>>>>> >
>>>>> >
>>>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>> >> James, do you want the sources or can you recommend me some
>>>>> actions? To
>>>>> >> create the session all the time, not to cache it?
>>>>> >>
>>>>> >> Adrian Tarau wrote:
>>>>> >> > Ok, so who close the session? :)
>>>>> >> >
>>>>> >> > James Strachan wrote:
>>>>> >> >> Sorry I forgot about that :)
>>>>> >> >>
>>>>> >> >> The only time a VM broker is shut down is explicitly via
>>>>> application
>>>>> >> >> code or a shutdown handler.
>>>>> >> >>
>>>>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>> >> >>> I use vm connector so no connection problems should be
>>>>> involved,
>>>>> >> right?
>>>>> >> >>>
>>>>> >> >>> James Strachan wrote:
>>>>> >> >>> > BTW are you using auto-reconnect? It could be that the
>>>>> socket is
>>>>> >> >>> > terminated due to some network issue?
>>>>> >> >>> >
>>>>> >> >>> >
>>>>> >> >>>
>>>>> >>
>>>>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>>>>
>>>>> >>
>>>>> >> >>>
>>>>> >> >>> >
>>>>> >> >>> >
>>>>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>> >> >>> >> I made a search for "close" in the source code and
>>>>> except from
>>>>> >> >>> produces,
>>>>> >> >>> >> consumers and inputstream and outputstream I don't close
>>>>> the
>>>>> >> >>> connection
>>>>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
>>>>> >> >>> >>
>>>>> >> >>> >> I can provide you(private - not on the mailing list) the
>>>>> >> source code
>>>>> >> >>> >> because this is very annoying.
>>>>> >> >>> >> Thanks.
>>>>> >> >>> >>
>>>>> >> >>> >> James Strachan wrote:
>>>>> >> >>> >> > Apart from inactivity timeouts on the transport layer, we
>>>>> >> >>> generally
>>>>> >> >>> >> > don't close sessions. Are you sure nothing in your
>>>>> application
>>>>> >> >>> code is
>>>>> >> >>> >> > trying to close the session?
>>>>> >> >>> >> >
>>>>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0 and
>>>>> 4.0.1.
>>>>> >> >>> >> >>
>>>>> >> >>> >> >> I use vm transport and create one session used to
>>>>> produce and
>>>>> >> >>> consume
>>>>> >> >>> >> >> messages. Everything works fine, days in a row, until it
>>>>> >> start to
>>>>> >> >>> >> throw
>>>>> >> >>> >> >> exception that "Session is closed". There are any watch
>>>>> >> dogs that
>>>>> >> >>> >> close
>>>>> >> >>> >> >> sessions after a while, based on some criteria?
>>>>> >> >>> >> >>
>>>>> >> >>> >> >> I couldn't find any rule, when or why it happens.
>>>>> >> >>> >> >> Should I create the session all the time - I
>>>>> understood is
>>>>> >> time
>>>>> >> >>> >> >> consuming and it should be safe to cache it.
>>>>> >> >>> >> >>
>>>>> >> >>> >> >> Thanks.
>>>>> >> >>> >> >>
>>>>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
>>>>> >> >>> >> >> at
>>>>> >> >>> >> >>
>>>>> >> >>> >>
>>>>> >> >>>
>>>>> >>
>>>>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
>>>>> :577)
>>>>> >>
>>>>> >> >>>
>>>>> >> >>> >>
>>>>> >> >>> >> >>
>>>>> >> >>> >> >> at
>>>>> >> >>> >> >>
>>>>> >> >>> >>
>>>>> >> >>>
>>>>> >>
>>>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
>>>>>
>>>>> :799)*
>>>>> >>
>>>>> >> >>>
>>>>> >> >>> >>
>>>>> >> >>> >> >>
>>>>> >> >>> >> >>
>>>>> >> >>> >> >>
>>>>> >> >>> >> >
>>>>> >> >>> >> >
>>>>> >> >>> >>
>>>>> >> >>> >>
>>>>> >> >>> >
>>>>> >> >>> >
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
Even more :)
As I told you I created a a Session wrapper over the ActiveMQ session in
order to catch the close call.
you can see down bellow the close method :
public void close() throws JMSException {
try {
IllegalAccessError illegalAccessError = new
IllegalAccessError("I don't want to close");
StringWriter sw = new StringWriter();
illegalAccessError.printStackTrace(new PrintWriter(sw));
LOG.error("Somebody closed the session, let's see who\n\n" +
sw.toString());
System.out.println("Somebody closed the session, let's see
who\n\n" + sw.toString());
} finally {
session.close();
}
}
Well, I looked in the error log, also looked in the container log(JBoss)
and didn't find any of theses strings "Somebody ...". The conclusion is
that nobody called close explicit on the session.
I placed that on 3 systems and over the weekend I got on all this
problem. One common thing between the systems is that are all loaded(are
test machines) and on all everything start to get "Session close" after
I got this exception(see bellow).
I don't know why we got java.io.InterruptedIOException:, it could be
possible because of me :). We interrupt the current thread(which consume
the message) if didn't respond after 60 secs(some kind of watchdog) so
it is possible to be because I call explicit Thread.interrupt().
Anyway, I thinkg, this should affect the sessions state(the close field
should not be turned false by any other piece of code, except close()
function, right?) should not be affected by am interrupt exception in a
consumer.
Thats all I could get about this problem with session close, anyway I
think I will create all the time the session, to avoid this problem.
Thanks.
2006-07-15 03:24:54,628 [AcitveMQ Connection Worker: vm://localhost#0]
ERROR com.daxtechnologies.sams.manager.SamsManagerJMS - JMS Error
javax.jms.JMSException: Interrupted.
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:45)
at
org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1462)
at
org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1478)
at
org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:94)
at
org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:120)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:94)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
at
org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:211)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:64)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
at
org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:68)
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:73)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
at
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
at
org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:196)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:840)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:800)
at
com.daxtechnologies.sams.manager.JmsSessionWrapper.createConsumer(JmsSessionWrapper.java:106)
at
com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:133)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
at
com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
Caused by: java.io.InterruptedIOException: Interrupted.
at
org.apache.activemq.transport.FutureResponse.set(FutureResponse.java:56)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:89)
... 23 more
2006-07-15 03:24:54,805 [SAMS-Worker-queue.contact_type-3] ERROR
com.daxtechnologies.sams.manager.AbstractSamsManagerQueue - Cannot
consume message from queue queue 'Contact Queue
<sy...@daxtechnologies.com>'
javax.jms.JMSException: Interrupted.
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1141)
at
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1667)
at
org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:516)
at
com.daxtechnologies.sams.manager.AbstractSamsManagerQueue.consume(AbstractSamsManagerQueue.java:145)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.consume(SamsManagerQueues.java:602)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.throttleQueue(SamsManagerQueues.java:571)
at
com.daxtechnologies.sams.manager.SamsManagerQueues$AbstractQueueRunnable.run(SamsManagerQueues.java:622)
at
com.daxtechnologies.sams.manager.SamsManagerThreadPool$WorkerThead.run(SamsManagerThreadPool.java:188)
Caused by: java.io.InterruptedIOException: Interrupted.
at
org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:40)
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1131)
... 7 more
Adrian Tarau wrote:
> More about closed session :)
>
> Could be possible that the closing problem could occur because the
> Session is not per Thread, even if it is accessed by only on thread at
> the time(or it should be accessed, but sometime is not -
> backport-concurent problems)?
>
> The code look like that :
> class MyStorageQueue {
> private Session session;
> private Queue queue;
> protected final Semaphore lock = new Semaphore(1, true);
> ....
> public Object consume() {
> ....
> }
>
> public void publish(Object object) {
> ....
> }
> }
>
> and usage in different threads
> MyStorageQueue queue = getNextQueue(...);
> if (queue.lock.tryAcquire()) {
> try {
> Object value = consume(queue);
> .....
> } finally {
> queue.lock.release();
> }
> }
>
> Anyway I created a wrapper over an ActiveMQ session, and dump the
> stack trace to see who calls the close method.
>
>
>
> Adrian Tarau wrote:
>> Debugging remove is not a problem, the problem is that I need to
>> start the application in debug mode and keep the IDE with a
>> breakpoint for days until it happens.
>>
>> I think I will recompile the ActiveMQ and dump the thread stack trace :)
>>
>> Sanjiv Jivan wrote:
>>> You can attach your debugger to the Java process on the remote
>>> machine and
>>> set the breakpoint on the session.close() call. Once the breakpoint
>>> it hit,
>>> you can examine the call stack in your debugger.
>>>
>>> Use the JPDA socket JVM args when starting your Java process. Eg :
>>> -Xdebug
>>> -Xnoagent
>>> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>>>
>>>
>>>
>>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>>
>>>> That's great but this usually happens on the remote machine, after
>>>> a few
>>>> days :)
>>>>
>>>> James Strachan wrote:
>>>> > Maybe try run your code in a debugger and set breakpoints in the
>>>> > ActiveMQSession class to see where & why the session gets closed?
>>>> (The
>>>> > code's pretty easy to follow, its a relatively simple class).
>>>> >
>>>> >
>>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>> >> James, do you want the sources or can you recommend me some
>>>> actions? To
>>>> >> create the session all the time, not to cache it?
>>>> >>
>>>> >> Adrian Tarau wrote:
>>>> >> > Ok, so who close the session? :)
>>>> >> >
>>>> >> > James Strachan wrote:
>>>> >> >> Sorry I forgot about that :)
>>>> >> >>
>>>> >> >> The only time a VM broker is shut down is explicitly via
>>>> application
>>>> >> >> code or a shutdown handler.
>>>> >> >>
>>>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>> >> >>> I use vm connector so no connection problems should be
>>>> involved,
>>>> >> right?
>>>> >> >>>
>>>> >> >>> James Strachan wrote:
>>>> >> >>> > BTW are you using auto-reconnect? It could be that the
>>>> socket is
>>>> >> >>> > terminated due to some network issue?
>>>> >> >>> >
>>>> >> >>> >
>>>> >> >>>
>>>> >>
>>>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>>>
>>>> >>
>>>> >> >>>
>>>> >> >>> >
>>>> >> >>> >
>>>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>> >> >>> >> I made a search for "close" in the source code and except
>>>> from
>>>> >> >>> produces,
>>>> >> >>> >> consumers and inputstream and outputstream I don't close the
>>>> >> >>> connection
>>>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
>>>> >> >>> >>
>>>> >> >>> >> I can provide you(private - not on the mailing list) the
>>>> >> source code
>>>> >> >>> >> because this is very annoying.
>>>> >> >>> >> Thanks.
>>>> >> >>> >>
>>>> >> >>> >> James Strachan wrote:
>>>> >> >>> >> > Apart from inactivity timeouts on the transport layer, we
>>>> >> >>> generally
>>>> >> >>> >> > don't close sessions. Are you sure nothing in your
>>>> application
>>>> >> >>> code is
>>>> >> >>> >> > trying to close the session?
>>>> >> >>> >> >
>>>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0 and
>>>> 4.0.1.
>>>> >> >>> >> >>
>>>> >> >>> >> >> I use vm transport and create one session used to
>>>> produce and
>>>> >> >>> consume
>>>> >> >>> >> >> messages. Everything works fine, days in a row, until it
>>>> >> start to
>>>> >> >>> >> throw
>>>> >> >>> >> >> exception that "Session is closed". There are any watch
>>>> >> dogs that
>>>> >> >>> >> close
>>>> >> >>> >> >> sessions after a while, based on some criteria?
>>>> >> >>> >> >>
>>>> >> >>> >> >> I couldn't find any rule, when or why it happens.
>>>> >> >>> >> >> Should I create the session all the time - I
>>>> understood is
>>>> >> time
>>>> >> >>> >> >> consuming and it should be safe to cache it.
>>>> >> >>> >> >>
>>>> >> >>> >> >> Thanks.
>>>> >> >>> >> >>
>>>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
>>>> >> >>> >> >> at
>>>> >> >>> >> >>
>>>> >> >>> >>
>>>> >> >>>
>>>> >>
>>>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
>>>> :577)
>>>> >>
>>>> >> >>>
>>>> >> >>> >>
>>>> >> >>> >> >>
>>>> >> >>> >> >> at
>>>> >> >>> >> >>
>>>> >> >>> >>
>>>> >> >>>
>>>> >>
>>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
>>>>
>>>> :799)*
>>>> >>
>>>> >> >>>
>>>> >> >>> >>
>>>> >> >>> >> >>
>>>> >> >>> >> >>
>>>> >> >>> >> >>
>>>> >> >>> >> >
>>>> >> >>> >> >
>>>> >> >>> >>
>>>> >> >>> >>
>>>> >> >>> >
>>>> >> >>> >
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >>
>>>> >> >
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
More about closed session :)
Could be possible that the closing problem could occur because the
Session is not per Thread, even if it is accessed by only on thread at
the time(or it should be accessed, but sometime is not -
backport-concurent problems)?
The code look like that :
class MyStorageQueue {
private Session session;
private Queue queue;
protected final Semaphore lock = new Semaphore(1, true);
....
public Object consume() {
....
}
public void publish(Object object) {
....
}
}
and usage in different threads
MyStorageQueue queue = getNextQueue(...);
if (queue.lock.tryAcquire()) {
try {
Object value = consume(queue);
.....
} finally {
queue.lock.release();
}
}
Anyway I created a wrapper over an ActiveMQ session, and dump the stack
trace to see who calls the close method.
Adrian Tarau wrote:
> Debugging remove is not a problem, the problem is that I need to start
> the application in debug mode and keep the IDE with a breakpoint for
> days until it happens.
>
> I think I will recompile the ActiveMQ and dump the thread stack trace :)
>
> Sanjiv Jivan wrote:
>> You can attach your debugger to the Java process on the remote
>> machine and
>> set the breakpoint on the session.close() call. Once the breakpoint
>> it hit,
>> you can examine the call stack in your debugger.
>>
>> Use the JPDA socket JVM args when starting your Java process. Eg :
>> -Xdebug
>> -Xnoagent
>> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>>
>>
>>
>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>>
>>> That's great but this usually happens on the remote machine, after a
>>> few
>>> days :)
>>>
>>> James Strachan wrote:
>>> > Maybe try run your code in a debugger and set breakpoints in the
>>> > ActiveMQSession class to see where & why the session gets closed?
>>> (The
>>> > code's pretty easy to follow, its a relatively simple class).
>>> >
>>> >
>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>> >> James, do you want the sources or can you recommend me some
>>> actions? To
>>> >> create the session all the time, not to cache it?
>>> >>
>>> >> Adrian Tarau wrote:
>>> >> > Ok, so who close the session? :)
>>> >> >
>>> >> > James Strachan wrote:
>>> >> >> Sorry I forgot about that :)
>>> >> >>
>>> >> >> The only time a VM broker is shut down is explicitly via
>>> application
>>> >> >> code or a shutdown handler.
>>> >> >>
>>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>> >> >>> I use vm connector so no connection problems should be involved,
>>> >> right?
>>> >> >>>
>>> >> >>> James Strachan wrote:
>>> >> >>> > BTW are you using auto-reconnect? It could be that the
>>> socket is
>>> >> >>> > terminated due to some network issue?
>>> >> >>> >
>>> >> >>> >
>>> >> >>>
>>> >>
>>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>>
>>> >>
>>> >> >>>
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>> >> >>> >> I made a search for "close" in the source code and except
>>> from
>>> >> >>> produces,
>>> >> >>> >> consumers and inputstream and outputstream I don't close the
>>> >> >>> connection
>>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
>>> >> >>> >>
>>> >> >>> >> I can provide you(private - not on the mailing list) the
>>> >> source code
>>> >> >>> >> because this is very annoying.
>>> >> >>> >> Thanks.
>>> >> >>> >>
>>> >> >>> >> James Strachan wrote:
>>> >> >>> >> > Apart from inactivity timeouts on the transport layer, we
>>> >> >>> generally
>>> >> >>> >> > don't close sessions. Are you sure nothing in your
>>> application
>>> >> >>> code is
>>> >> >>> >> > trying to close the session?
>>> >> >>> >> >
>>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0 and
>>> 4.0.1.
>>> >> >>> >> >>
>>> >> >>> >> >> I use vm transport and create one session used to
>>> produce and
>>> >> >>> consume
>>> >> >>> >> >> messages. Everything works fine, days in a row, until it
>>> >> start to
>>> >> >>> >> throw
>>> >> >>> >> >> exception that "Session is closed". There are any watch
>>> >> dogs that
>>> >> >>> >> close
>>> >> >>> >> >> sessions after a while, based on some criteria?
>>> >> >>> >> >>
>>> >> >>> >> >> I couldn't find any rule, when or why it happens.
>>> >> >>> >> >> Should I create the session all the time - I
>>> understood is
>>> >> time
>>> >> >>> >> >> consuming and it should be safe to cache it.
>>> >> >>> >> >>
>>> >> >>> >> >> Thanks.
>>> >> >>> >> >>
>>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
>>> >> >>> >> >> at
>>> >> >>> >> >>
>>> >> >>> >>
>>> >> >>>
>>> >> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
>>> :577)
>>> >>
>>> >> >>>
>>> >> >>> >>
>>> >> >>> >> >>
>>> >> >>> >> >> at
>>> >> >>> >> >>
>>> >> >>> >>
>>> >> >>>
>>> >>
>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
>>> :799)*
>>> >>
>>> >> >>>
>>> >> >>> >>
>>> >> >>> >> >>
>>> >> >>> >> >>
>>> >> >>> >> >>
>>> >> >>> >> >
>>> >> >>> >> >
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >
>>> >> >>> >
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
Debugging remove is not a problem, the problem is that I need to start
the application in debug mode and keep the IDE with a breakpoint for
days until it happens.
I think I will recompile the ActiveMQ and dump the thread stack trace :)
Sanjiv Jivan wrote:
> You can attach your debugger to the Java process on the remote machine
> and
> set the breakpoint on the session.close() call. Once the breakpoint it
> hit,
> you can examine the call stack in your debugger.
>
> Use the JPDA socket JVM args when starting your Java process. Eg :
> -Xdebug
> -Xnoagent
> -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
>
>
>
> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>
>> That's great but this usually happens on the remote machine, after a few
>> days :)
>>
>> James Strachan wrote:
>> > Maybe try run your code in a debugger and set breakpoints in the
>> > ActiveMQSession class to see where & why the session gets closed? (The
>> > code's pretty easy to follow, its a relatively simple class).
>> >
>> >
>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >> James, do you want the sources or can you recommend me some
>> actions? To
>> >> create the session all the time, not to cache it?
>> >>
>> >> Adrian Tarau wrote:
>> >> > Ok, so who close the session? :)
>> >> >
>> >> > James Strachan wrote:
>> >> >> Sorry I forgot about that :)
>> >> >>
>> >> >> The only time a VM broker is shut down is explicitly via
>> application
>> >> >> code or a shutdown handler.
>> >> >>
>> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >> >>> I use vm connector so no connection problems should be involved,
>> >> right?
>> >> >>>
>> >> >>> James Strachan wrote:
>> >> >>> > BTW are you using auto-reconnect? It could be that the
>> socket is
>> >> >>> > terminated due to some network issue?
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >>
>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>
>> >>
>> >> >>>
>> >> >>> >
>> >> >>> >
>> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >> >>> >> I made a search for "close" in the source code and except from
>> >> >>> produces,
>> >> >>> >> consumers and inputstream and outputstream I don't close the
>> >> >>> connection
>> >> >>> >> or session, except on the JVM shutdown(Thread hook).
>> >> >>> >>
>> >> >>> >> I can provide you(private - not on the mailing list) the
>> >> source code
>> >> >>> >> because this is very annoying.
>> >> >>> >> Thanks.
>> >> >>> >>
>> >> >>> >> James Strachan wrote:
>> >> >>> >> > Apart from inactivity timeouts on the transport layer, we
>> >> >>> generally
>> >> >>> >> > don't close sessions. Are you sure nothing in your
>> application
>> >> >>> code is
>> >> >>> >> > trying to close the session?
>> >> >>> >> >
>> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0 and
>> 4.0.1.
>> >> >>> >> >>
>> >> >>> >> >> I use vm transport and create one session used to
>> produce and
>> >> >>> consume
>> >> >>> >> >> messages. Everything works fine, days in a row, until it
>> >> start to
>> >> >>> >> throw
>> >> >>> >> >> exception that "Session is closed". There are any watch
>> >> dogs that
>> >> >>> >> close
>> >> >>> >> >> sessions after a while, based on some criteria?
>> >> >>> >> >>
>> >> >>> >> >> I couldn't find any rule, when or why it happens.
>> >> >>> >> >> Should I create the session all the time - I understood is
>> >> time
>> >> >>> >> >> consuming and it should be safe to cache it.
>> >> >>> >> >>
>> >> >>> >> >> Thanks.
>> >> >>> >> >>
>> >> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
>> >> >>> >> >> at
>> >> >>> >> >>
>> >> >>> >>
>> >> >>>
>> >> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
>> :577)
>> >>
>> >> >>>
>> >> >>> >>
>> >> >>> >> >>
>> >> >>> >> >> at
>> >> >>> >> >>
>> >> >>> >>
>> >> >>>
>> >>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
>> :799)*
>> >>
>> >> >>>
>> >> >>> >>
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >>
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
Re: Session closed after a while(random)
Posted by Sanjiv Jivan <sa...@gmail.com>.
You can attach your debugger to the Java process on the remote machine and
set the breakpoint on the session.close() call. Once the breakpoint it hit,
you can examine the call stack in your debugger.
Use the JPDA socket JVM args when starting your Java process. Eg : -Xdebug
-Xnoagent -Djava.compiler=NONE-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>
> That's great but this usually happens on the remote machine, after a few
> days :)
>
> James Strachan wrote:
> > Maybe try run your code in a debugger and set breakpoints in the
> > ActiveMQSession class to see where & why the session gets closed? (The
> > code's pretty easy to follow, its a relatively simple class).
> >
> >
> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >> James, do you want the sources or can you recommend me some actions? To
> >> create the session all the time, not to cache it?
> >>
> >> Adrian Tarau wrote:
> >> > Ok, so who close the session? :)
> >> >
> >> > James Strachan wrote:
> >> >> Sorry I forgot about that :)
> >> >>
> >> >> The only time a VM broker is shut down is explicitly via application
> >> >> code or a shutdown handler.
> >> >>
> >> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >> >>> I use vm connector so no connection problems should be involved,
> >> right?
> >> >>>
> >> >>> James Strachan wrote:
> >> >>> > BTW are you using auto-reconnect? It could be that the socket is
> >> >>> > terminated due to some network issue?
> >> >>> >
> >> >>> >
> >> >>>
> >>
> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
> >>
> >> >>>
> >> >>> >
> >> >>> >
> >> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >> >>> >> I made a search for "close" in the source code and except from
> >> >>> produces,
> >> >>> >> consumers and inputstream and outputstream I don't close the
> >> >>> connection
> >> >>> >> or session, except on the JVM shutdown(Thread hook).
> >> >>> >>
> >> >>> >> I can provide you(private - not on the mailing list) the
> >> source code
> >> >>> >> because this is very annoying.
> >> >>> >> Thanks.
> >> >>> >>
> >> >>> >> James Strachan wrote:
> >> >>> >> > Apart from inactivity timeouts on the transport layer, we
> >> >>> generally
> >> >>> >> > don't close sessions. Are you sure nothing in your application
> >> >>> code is
> >> >>> >> > trying to close the session?
> >> >>> >> >
> >> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >> >>> >> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
> >> >>> >> >>
> >> >>> >> >> I use vm transport and create one session used to produce and
> >> >>> consume
> >> >>> >> >> messages. Everything works fine, days in a row, until it
> >> start to
> >> >>> >> throw
> >> >>> >> >> exception that "Session is closed". There are any watch
> >> dogs that
> >> >>> >> close
> >> >>> >> >> sessions after a while, based on some criteria?
> >> >>> >> >>
> >> >>> >> >> I couldn't find any rule, when or why it happens.
> >> >>> >> >> Should I create the session all the time - I understood is
> >> time
> >> >>> >> >> consuming and it should be safe to cache it.
> >> >>> >> >>
> >> >>> >> >> Thanks.
> >> >>> >> >>
> >> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
> >> >>> >> >> at
> >> >>> >> >>
> >> >>> >>
> >> >>>
> >> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java
> :577)
> >>
> >> >>>
> >> >>> >>
> >> >>> >> >>
> >> >>> >> >> at
> >> >>> >> >>
> >> >>> >>
> >> >>>
> >> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java
> :799)*
> >>
> >> >>>
> >> >>> >>
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >
> >> >>> >> >
> >> >>> >>
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
That's great but this usually happens on the remote machine, after a few
days :)
James Strachan wrote:
> Maybe try run your code in a debugger and set breakpoints in the
> ActiveMQSession class to see where & why the session gets closed? (The
> code's pretty easy to follow, its a relatively simple class).
>
>
> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> James, do you want the sources or can you recommend me some actions? To
>> create the session all the time, not to cache it?
>>
>> Adrian Tarau wrote:
>> > Ok, so who close the session? :)
>> >
>> > James Strachan wrote:
>> >> Sorry I forgot about that :)
>> >>
>> >> The only time a VM broker is shut down is explicitly via application
>> >> code or a shutdown handler.
>> >>
>> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >>> I use vm connector so no connection problems should be involved,
>> right?
>> >>>
>> >>> James Strachan wrote:
>> >>> > BTW are you using auto-reconnect? It could be that the socket is
>> >>> > terminated due to some network issue?
>> >>> >
>> >>> >
>> >>>
>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>
>> >>>
>> >>> >
>> >>> >
>> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >>> >> I made a search for "close" in the source code and except from
>> >>> produces,
>> >>> >> consumers and inputstream and outputstream I don't close the
>> >>> connection
>> >>> >> or session, except on the JVM shutdown(Thread hook).
>> >>> >>
>> >>> >> I can provide you(private - not on the mailing list) the
>> source code
>> >>> >> because this is very annoying.
>> >>> >> Thanks.
>> >>> >>
>> >>> >> James Strachan wrote:
>> >>> >> > Apart from inactivity timeouts on the transport layer, we
>> >>> generally
>> >>> >> > don't close sessions. Are you sure nothing in your application
>> >>> code is
>> >>> >> > trying to close the session?
>> >>> >> >
>> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >>> >> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
>> >>> >> >>
>> >>> >> >> I use vm transport and create one session used to produce and
>> >>> consume
>> >>> >> >> messages. Everything works fine, days in a row, until it
>> start to
>> >>> >> throw
>> >>> >> >> exception that "Session is closed". There are any watch
>> dogs that
>> >>> >> close
>> >>> >> >> sessions after a while, based on some criteria?
>> >>> >> >>
>> >>> >> >> I couldn't find any rule, when or why it happens.
>> >>> >> >> Should I create the session all the time - I understood is
>> time
>> >>> >> >> consuming and it should be safe to cache it.
>> >>> >> >>
>> >>> >> >> Thanks.
>> >>> >> >>
>> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
>> >>> >> >> at
>> >>> >> >>
>> >>> >>
>> >>>
>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
>>
>> >>>
>> >>> >>
>> >>> >> >>
>> >>> >> >> at
>> >>> >> >>
>> >>> >>
>> >>>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
>>
>> >>>
>> >>> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>
>> >>
>> >
>>
>>
>
>
Re: Session closed after a while(random)
Posted by James Strachan <ja...@gmail.com>.
Maybe try run your code in a debugger and set breakpoints in the
ActiveMQSession class to see where & why the session gets closed? (The
code's pretty easy to follow, its a relatively simple class).
On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> James, do you want the sources or can you recommend me some actions? To
> create the session all the time, not to cache it?
>
> Adrian Tarau wrote:
> > Ok, so who close the session? :)
> >
> > James Strachan wrote:
> >> Sorry I forgot about that :)
> >>
> >> The only time a VM broker is shut down is explicitly via application
> >> code or a shutdown handler.
> >>
> >> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >>> I use vm connector so no connection problems should be involved, right?
> >>>
> >>> James Strachan wrote:
> >>> > BTW are you using auto-reconnect? It could be that the socket is
> >>> > terminated due to some network issue?
> >>> >
> >>> >
> >>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
> >>>
> >>> >
> >>> >
> >>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >>> >> I made a search for "close" in the source code and except from
> >>> produces,
> >>> >> consumers and inputstream and outputstream I don't close the
> >>> connection
> >>> >> or session, except on the JVM shutdown(Thread hook).
> >>> >>
> >>> >> I can provide you(private - not on the mailing list) the source code
> >>> >> because this is very annoying.
> >>> >> Thanks.
> >>> >>
> >>> >> James Strachan wrote:
> >>> >> > Apart from inactivity timeouts on the transport layer, we
> >>> generally
> >>> >> > don't close sessions. Are you sure nothing in your application
> >>> code is
> >>> >> > trying to close the session?
> >>> >> >
> >>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >>> >> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
> >>> >> >>
> >>> >> >> I use vm transport and create one session used to produce and
> >>> consume
> >>> >> >> messages. Everything works fine, days in a row, until it start to
> >>> >> throw
> >>> >> >> exception that "Session is closed". There are any watch dogs that
> >>> >> close
> >>> >> >> sessions after a while, based on some criteria?
> >>> >> >>
> >>> >> >> I couldn't find any rule, when or why it happens.
> >>> >> >> Should I create the session all the time - I understood is time
> >>> >> >> consuming and it should be safe to cache it.
> >>> >> >>
> >>> >> >> Thanks.
> >>> >> >>
> >>> >> >> *javax.jms.IllegalStateException: The Session is closed
> >>> >> >> at
> >>> >> >>
> >>> >>
> >>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
> >>>
> >>> >>
> >>> >> >>
> >>> >> >> at
> >>> >> >>
> >>> >>
> >>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
> >>>
> >>> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>>
> >>>
> >>
> >>
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
James, do you want the sources or can you recommend me some actions? To
create the session all the time, not to cache it?
Adrian Tarau wrote:
> Ok, so who close the session? :)
>
> James Strachan wrote:
>> Sorry I forgot about that :)
>>
>> The only time a VM broker is shut down is explicitly via application
>> code or a shutdown handler.
>>
>> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>> I use vm connector so no connection problems should be involved, right?
>>>
>>> James Strachan wrote:
>>> > BTW are you using auto-reconnect? It could be that the socket is
>>> > terminated due to some network issue?
>>> >
>>> >
>>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>>
>>> >
>>> >
>>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>> >> I made a search for "close" in the source code and except from
>>> produces,
>>> >> consumers and inputstream and outputstream I don't close the
>>> connection
>>> >> or session, except on the JVM shutdown(Thread hook).
>>> >>
>>> >> I can provide you(private - not on the mailing list) the source code
>>> >> because this is very annoying.
>>> >> Thanks.
>>> >>
>>> >> James Strachan wrote:
>>> >> > Apart from inactivity timeouts on the transport layer, we
>>> generally
>>> >> > don't close sessions. Are you sure nothing in your application
>>> code is
>>> >> > trying to close the session?
>>> >> >
>>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>>> >> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
>>> >> >>
>>> >> >> I use vm transport and create one session used to produce and
>>> consume
>>> >> >> messages. Everything works fine, days in a row, until it start to
>>> >> throw
>>> >> >> exception that "Session is closed". There are any watch dogs that
>>> >> close
>>> >> >> sessions after a while, based on some criteria?
>>> >> >>
>>> >> >> I couldn't find any rule, when or why it happens.
>>> >> >> Should I create the session all the time - I understood is time
>>> >> >> consuming and it should be safe to cache it.
>>> >> >>
>>> >> >> Thanks.
>>> >> >>
>>> >> >> *javax.jms.IllegalStateException: The Session is closed
>>> >> >> at
>>> >> >>
>>> >>
>>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
>>>
>>> >>
>>> >> >>
>>> >> >> at
>>> >> >>
>>> >>
>>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
>>>
>>> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
Ok, so who close the session? :)
James Strachan wrote:
> Sorry I forgot about that :)
>
> The only time a VM broker is shut down is explicitly via application
> code or a shutdown handler.
>
> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> I use vm connector so no connection problems should be involved, right?
>>
>> James Strachan wrote:
>> > BTW are you using auto-reconnect? It could be that the socket is
>> > terminated due to some network issue?
>> >
>> >
>> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>>
>> >
>> >
>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >> I made a search for "close" in the source code and except from
>> produces,
>> >> consumers and inputstream and outputstream I don't close the
>> connection
>> >> or session, except on the JVM shutdown(Thread hook).
>> >>
>> >> I can provide you(private - not on the mailing list) the source code
>> >> because this is very annoying.
>> >> Thanks.
>> >>
>> >> James Strachan wrote:
>> >> > Apart from inactivity timeouts on the transport layer, we generally
>> >> > don't close sessions. Are you sure nothing in your application
>> code is
>> >> > trying to close the session?
>> >> >
>> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
>> >> >>
>> >> >> I use vm transport and create one session used to produce and
>> consume
>> >> >> messages. Everything works fine, days in a row, until it start to
>> >> throw
>> >> >> exception that "Session is closed". There are any watch dogs that
>> >> close
>> >> >> sessions after a while, based on some criteria?
>> >> >>
>> >> >> I couldn't find any rule, when or why it happens.
>> >> >> Should I create the session all the time - I understood is time
>> >> >> consuming and it should be safe to cache it.
>> >> >>
>> >> >> Thanks.
>> >> >>
>> >> >> *javax.jms.IllegalStateException: The Session is closed
>> >> >> at
>> >> >>
>> >>
>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
>>
>> >>
>> >> >>
>> >> >> at
>> >> >>
>> >>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
>>
>> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: Session closed after a while(random)
Posted by James Strachan <ja...@gmail.com>.
Sorry I forgot about that :)
The only time a VM broker is shut down is explicitly via application
code or a shutdown handler.
On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> I use vm connector so no connection problems should be involved, right?
>
> James Strachan wrote:
> > BTW are you using auto-reconnect? It could be that the socket is
> > terminated due to some network issue?
> >
> > http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
> >
> >
> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >> I made a search for "close" in the source code and except from produces,
> >> consumers and inputstream and outputstream I don't close the connection
> >> or session, except on the JVM shutdown(Thread hook).
> >>
> >> I can provide you(private - not on the mailing list) the source code
> >> because this is very annoying.
> >> Thanks.
> >>
> >> James Strachan wrote:
> >> > Apart from inactivity timeouts on the transport layer, we generally
> >> > don't close sessions. Are you sure nothing in your application code is
> >> > trying to close the session?
> >> >
> >> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
> >> >>
> >> >> I use vm transport and create one session used to produce and consume
> >> >> messages. Everything works fine, days in a row, until it start to
> >> throw
> >> >> exception that "Session is closed". There are any watch dogs that
> >> close
> >> >> sessions after a while, based on some criteria?
> >> >>
> >> >> I couldn't find any rule, when or why it happens.
> >> >> Should I create the session all the time - I understood is time
> >> >> consuming and it should be safe to cache it.
> >> >>
> >> >> Thanks.
> >> >>
> >> >> *javax.jms.IllegalStateException: The Session is closed
> >> >> at
> >> >>
> >> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
> >>
> >> >>
> >> >> at
> >> >>
> >> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
I use vm connector so no connection problems should be involved, right?
James Strachan wrote:
> BTW are you using auto-reconnect? It could be that the socket is
> terminated due to some network issue?
>
> http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
>
>
> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> I made a search for "close" in the source code and except from produces,
>> consumers and inputstream and outputstream I don't close the connection
>> or session, except on the JVM shutdown(Thread hook).
>>
>> I can provide you(private - not on the mailing list) the source code
>> because this is very annoying.
>> Thanks.
>>
>> James Strachan wrote:
>> > Apart from inactivity timeouts on the transport layer, we generally
>> > don't close sessions. Are you sure nothing in your application code is
>> > trying to close the session?
>> >
>> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
>> >>
>> >> I use vm transport and create one session used to produce and consume
>> >> messages. Everything works fine, days in a row, until it start to
>> throw
>> >> exception that "Session is closed". There are any watch dogs that
>> close
>> >> sessions after a while, based on some criteria?
>> >>
>> >> I couldn't find any rule, when or why it happens.
>> >> Should I create the session all the time - I understood is time
>> >> consuming and it should be safe to cache it.
>> >>
>> >> Thanks.
>> >>
>> >> *javax.jms.IllegalStateException: The Session is closed
>> >> at
>> >>
>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
>>
>> >>
>> >> at
>> >>
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
>>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: Session closed after a while(random)
Posted by James Strachan <ja...@gmail.com>.
BTW are you using auto-reconnect? It could be that the socket is
terminated due to some network issue?
http://incubator.apache.org/activemq/how-can-i-support-auto-reconnection.html
On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> I made a search for "close" in the source code and except from produces,
> consumers and inputstream and outputstream I don't close the connection
> or session, except on the JVM shutdown(Thread hook).
>
> I can provide you(private - not on the mailing list) the source code
> because this is very annoying.
> Thanks.
>
> James Strachan wrote:
> > Apart from inactivity timeouts on the transport layer, we generally
> > don't close sessions. Are you sure nothing in your application code is
> > trying to close the session?
> >
> > On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> >> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
> >>
> >> I use vm transport and create one session used to produce and consume
> >> messages. Everything works fine, days in a row, until it start to throw
> >> exception that "Session is closed". There are any watch dogs that close
> >> sessions after a while, based on some criteria?
> >>
> >> I couldn't find any rule, when or why it happens.
> >> Should I create the session all the time - I understood is time
> >> consuming and it should be safe to cache it.
> >>
> >> Thanks.
> >>
> >> *javax.jms.IllegalStateException: The Session is closed
> >> at
> >> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
> >>
> >> at
> >> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
> >>
> >>
> >>
> >
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
I made a search for "close" in the source code and except from produces,
consumers and inputstream and outputstream I don't close the connection
or session, except on the JVM shutdown(Thread hook).
I can provide you(private - not on the mailing list) the source code
because this is very annoying.
Thanks.
James Strachan wrote:
> Apart from inactivity timeouts on the transport layer, we generally
> don't close sessions. Are you sure nothing in your application code is
> trying to close the session?
>
> On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
>> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
>>
>> I use vm transport and create one session used to produce and consume
>> messages. Everything works fine, days in a row, until it start to throw
>> exception that "Session is closed". There are any watch dogs that close
>> sessions after a while, based on some criteria?
>>
>> I couldn't find any rule, when or why it happens.
>> Should I create the session all the time - I understood is time
>> consuming and it should be safe to cache it.
>>
>> Thanks.
>>
>> *javax.jms.IllegalStateException: The Session is closed
>> at
>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
>>
>> at
>> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
>>
>>
>>
>
>
Re: Session closed after a while(random)
Posted by James Strachan <ja...@gmail.com>.
Apart from inactivity timeouts on the transport layer, we generally
don't close sessions. Are you sure nothing in your application code is
trying to close the session?
On 7/13/06, Adrian Tarau <ad...@daxtechnologies.com> wrote:
> I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
>
> I use vm transport and create one session used to produce and consume
> messages. Everything works fine, days in a row, until it start to throw
> exception that "Session is closed". There are any watch dogs that close
> sessions after a while, based on some criteria?
>
> I couldn't find any rule, when or why it happens.
> Should I create the session all the time - I understood is time
> consuming and it should be safe to cache it.
>
> Thanks.
>
> *javax.jms.IllegalStateException: The Session is closed
> at
> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
> at
> org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Session closed after a while(random)
Posted by Adrian Tarau <ad...@daxtechnologies.com>.
I have this issue for some time with ActiveMQ 4.0 and 4.0.1.
I use vm transport and create one session used to produce and consume
messages. Everything works fine, days in a row, until it start to throw
exception that "Session is closed". There are any watch dogs that close
sessions after a while, based on some criteria?
I couldn't find any rule, when or why it happens.
Should I create the session all the time - I understood is time
consuming and it should be safe to cache it.
Thanks.
*javax.jms.IllegalStateException: The Session is closed
at
org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:577)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:799)*
RE: activemq from C++ application in linux and window
Posted by Timothy Bish <ta...@twcny.rr.com>.
Sanjiv
You design does sound interesting. Its been awhile since I've done any JNI
coding. As with anything there are tradeoffs that you make when you go that
route, as I recall marshalling between contexts can be a big hit to overall
app performance, but at the end of the day, if it meets your requirements
then you can't complain to much.
As far as the cross platform threading issues go, we have created a fairly
nice Threading implementation in the new activemq-cpp that resembles java
threading in its use, and has been tested pretty heavily on Windows and
Linux, we still need to hit OSX and Solaris.
-------------------------------------------------
Timothy A. Bish
-----Original Message-----
From: Sanjiv Jivan [mailto:sanjiv.jivan@gmail.com]
Sent: Thursday, July 13, 2006 7:29 AM
To: activemq-users@geronimo.apache.org
Subject: Re: activemq from C++ application in linux and window
Importance: High
In our project, we embedded a JVM in the C++ app, and exposed methods for
inbound -> C++ delegation and C++ --> JNI method to send messages using the
JNI RegisterNatives function. This helps us do all our jms configuration
using Spring and also keeps the messaging code in Java. The ActiveMQ
java-java communication seemed more mature than the C++ portion and it also
kept us away from cross platform threading issues associated with C++ apps.
Any comments on this approach?
Sanjiv
On 7/13/06, Nathan Mittler <na...@gmail.com> wrote:
>
> Hi Vishu,
> comments inline ...
>
> On 7/13/06, Vishu <vk...@yahoo.com> wrote:
> >
> >
> > Hi Nate,
> > Thanks a lot for your response.
> > Sorry for bug you again asking stupid questions
> > My requirement is something like. There are two applications one main
> > application (App1) written in C++ and second application (app2) written
> in
> > Java. Where App1 will be publishing messages regularly (the no may be
> 1000
> > message per second or more) these messages need to go to Activemq and
> App2
> > should be able to subscribe for those message.
>
>
> I see no problems with the data load, in our testing we were sending
> several
> thousand messages all at once.
>
>
> I need a persistence
> > messaging no message should be lost. Because App1 and App2 are running
> on
> > different m/c?s and may not be running at the same time.
>
> But looking at
> > http://www.activemq.org/site/activemq-cpp-roadmap.html
> > There is known issue
> > After committing a transaction, the consumer seems to stop getting
> > messages
> > after around 999/1000 messages. We think this is a bug at the broker,
> but
> > more investigation is needed.
>
>
> It may be worth noting that this test was done from C++ client to C++
> client
> which may have different results than going from Java->C++. So it may be
> worth your time giving it a shot as you should be able to set up a test
> fairly quickly.
>
> Also I don't know whether they have had any release of ActiveMq C++
> client,
> > I did not find that on web or is it yet to be released it is still under
> > development.
>
>
> There is no official release yet, as we're still doing some cleanup before
> we begin to port the openwire C++ client. I'm guessing that once we get
> openwire in, we'll begin to be incorporated in the mainline release cycle
> with the rest of AMQ.
>
> --
> > View this message in context:
> >
>
http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-
tf1932905.html#a5302652
> > Sent from the ActiveMQ - User forum at Nabble.com.
>
>
> Regards,
> Nate
>
>
Re: activemq from C++ application in linux and window
Posted by Sanjiv Jivan <sa...@gmail.com>.
In our project, we embedded a JVM in the C++ app, and exposed methods for
inbound -> C++ delegation and C++ --> JNI method to send messages using the
JNI RegisterNatives function. This helps us do all our jms configuration
using Spring and also keeps the messaging code in Java. The ActiveMQ
java-java communication seemed more mature than the C++ portion and it also
kept us away from cross platform threading issues associated with C++ apps.
Any comments on this approach?
Sanjiv
On 7/13/06, Nathan Mittler <na...@gmail.com> wrote:
>
> Hi Vishu,
> comments inline ...
>
> On 7/13/06, Vishu <vk...@yahoo.com> wrote:
> >
> >
> > Hi Nate,
> > Thanks a lot for your response.
> > Sorry for bug you again asking stupid questions
> > My requirement is something like. There are two applications one main
> > application (App1) written in C++ and second application (app2) written
> in
> > Java. Where App1 will be publishing messages regularly (the no may be
> 1000
> > message per second or more) these messages need to go to Activemq and
> App2
> > should be able to subscribe for those message.
>
>
> I see no problems with the data load, in our testing we were sending
> several
> thousand messages all at once.
>
>
> I need a persistence
> > messaging no message should be lost. Because App1 and App2 are running
> on
> > different m/c?s and may not be running at the same time.
>
> But looking at
> > http://www.activemq.org/site/activemq-cpp-roadmap.html
> > There is known issue
> > After committing a transaction, the consumer seems to stop getting
> > messages
> > after around 999/1000 messages. We think this is a bug at the broker,
> but
> > more investigation is needed.
>
>
> It may be worth noting that this test was done from C++ client to C++
> client
> which may have different results than going from Java->C++. So it may be
> worth your time giving it a shot as you should be able to set up a test
> fairly quickly.
>
> Also I don't know whether they have had any release of ActiveMq C++
> client,
> > I did not find that on web or is it yet to be released it is still under
> > development.
>
>
> There is no official release yet, as we're still doing some cleanup before
> we begin to port the openwire C++ client. I'm guessing that once we get
> openwire in, we'll begin to be incorporated in the mainline release cycle
> with the rest of AMQ.
>
> --
> > View this message in context:
> >
> http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-tf1932905.html#a5302652
> > Sent from the ActiveMQ - User forum at Nabble.com.
>
>
> Regards,
> Nate
>
>
Re: activemq from C++ application in linux and window
Posted by Nathan Mittler <na...@gmail.com>.
Hi Vishu,
comments inline ...
On 7/13/06, Vishu <vk...@yahoo.com> wrote:
>
>
> Hi Nate,
> Thanks a lot for your response.
> Sorry for bug you again asking stupid questions
> My requirement is something like. There are two applications one main
> application (App1) written in C++ and second application (app2) written in
> Java. Where App1 will be publishing messages regularly (the no may be 1000
> message per second or more) these messages need to go to Activemq and App2
> should be able to subscribe for those message.
I see no problems with the data load, in our testing we were sending several
thousand messages all at once.
I need a persistence
> messaging no message should be lost. Because App1 and App2 are running on
> different m/c?s and may not be running at the same time.
But looking at
> http://www.activemq.org/site/activemq-cpp-roadmap.html
> There is known issue
> After committing a transaction, the consumer seems to stop getting
> messages
> after around 999/1000 messages. We think this is a bug at the broker, but
> more investigation is needed.
It may be worth noting that this test was done from C++ client to C++ client
which may have different results than going from Java->C++. So it may be
worth your time giving it a shot as you should be able to set up a test
fairly quickly.
Also I don't know whether they have had any release of ActiveMq C++ client,
> I did not find that on web or is it yet to be released it is still under
> development.
There is no official release yet, as we're still doing some cleanup before
we begin to port the openwire C++ client. I'm guessing that once we get
openwire in, we'll begin to be incorporated in the mainline release cycle
with the rest of AMQ.
--
> View this message in context:
> http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-tf1932905.html#a5302652
> Sent from the ActiveMQ - User forum at Nabble.com.
Regards,
Nate
Re: activemq from C++ application in linux and window
Posted by Vishu <vk...@yahoo.com>.
Hi Nate,
Thanks a lot for your response.
Sorry for bug you again asking stupid questions
My requirement is something like. There are two applications one main
application (App1) written in C++ and second application (app2) written in
Java. Where App1 will be publishing messages regularly (the no may be 1000
message per second or more) these messages need to go to Activemq and App2
should be able to subscribe for those message. I need a persistence
messaging no message should be lost. Because App1 and App2 are running on
different m/c?s and may not be running at the same time.
But looking at
http://www.activemq.org/site/activemq-cpp-roadmap.html
There is known issue
After committing a transaction, the consumer seems to stop getting messages
after around 999/1000 messages. We think this is a bug at the broker, but
more investigation is needed.
Also I don't know whether they have had any release of ActiveMq C++ client,
I did not find that on web or is it yet to be released it is still under
development.
--
View this message in context: http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-tf1932905.html#a5302652
Sent from the ActiveMQ - User forum at Nabble.com.
Re: activemq from C++ application in linux and window
Posted by Nathan Mittler <na...@gmail.com>.
Hi Vishu,
The activemq-cpp client is probably your best bet - it should get you up and
running quickly. This page will point you to the source and show you an
example of usage:
http://www.activemq.org/site/activemq-cpp-client.html
You'll have to build it yourself, as it's not part of AMQ distributions.
But you're in luck since most of our building and testing has been done on
linux and windows.
One note, you'll need to run this against AMQ 4.0.1 or later. If that's not
an option, then you can try the CMS client (
http://www.activemq.org/site/cms.html) or the Openwire CPP client (
http://www.activemq.org/site/openwire-cpp-client.html).
Regards,
Nate
On 7/12/06, Vishu <vk...@yahoo.com> wrote:
>
>
> Hi,
>
> Am completely new to Java. I have application written in C++ and it is
> ported on Linux and Windows. I want to use Activemq from my application
> which can work on Linux and Windows platform. Can someone advice me quick
> solution
>
> Thanks in advance
> vishu
>
>
> --
> View this message in context:
> http://www.nabble.com/activemq-from-C%2B%2B-application-in-linux-and-window-tf1932905.html#a5295304
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>