qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Qpid topic sessions linger
Date Tue, 07 Jan 2014 21:38:30 GMT
Hi Logan,

unfortunately the mailing list strips off attachments - can you raise a
JIRA for this issue (go to: https://issues.apache.org/jira/browse/QPID) and
attach your code to that?

thanks,
Rob




On 7 January 2014 22:27, Logan Barnett <lbarnett@elinemedia.com> wrote:

> I’m pretty stumped here - I’ve went through the docs/wiki/jira as best I
> could, but couldn’t find anything on it at all - so I must be doing
> something really wrong here, apologies if I missed the doc that would have
> sorted this out.
>
> I’m trying to test various JMS features in Qpid so I can demo/pitch it to
> the rest of my team. My problem is that server-side sessions appear to
> linger long after my sessions are closed gracefully on the client side.
>
> I’ve attached my current code, which has the test for durable
> subscriptions as the active test. I’ve left commented various permutations
> I’ve tried to make things work so what I’ve attempted can be seen.
>
> When running the program, it completes successfully and demonstrates
> durable subscriptions do indeed work. No surprise there. When running the
> program again, the session.createDurableSubscriber call stalls for a while.
> Eventually it times out with this message:
>
> Exception in thread "main" javax.jms.JMSException: Error registering
> consumer: org.apache.qpid.AMQException: timed out waiting for sync:
> complete = 4, point = 9 [error code 541: internal error]
>
> On the server side, this is what I get during a failing run:
>
> 2014-01-07 12:51:06,805 INFO  [IoReceiver - /127.0.0.1:51065]
> (connection.open) - [con:124(/127.0.0.1:51065)] CON-1001 : Open
> 2014-01-07 12:51:06,809 INFO  [IoReceiver - /127.0.0.1:51065]
> (connection.open) - [con:124(/127.0.0.1:51065)] CON-1001 : Open :
> Protocol Version : 0-10
> 2014-01-07 12:51:07,266 INFO  [IoReceiver - /127.0.0.1:51065]
> (connection.open) - [con:124(guest@/127.0.0.1:51065/default)] CON-1001 :
> Open : Client ID : subscriber : Protocol Version : 0-10 : Client Version :
> 0.24
> 2014-01-07 12:51:07,305 INFO  [IoReceiver - /127.0.0.1:51065]
> (channel.create) - [con:124(subscriber@/127.0.0.1:51065/default)/ch:0]
> CHN-1001 : Create
> 2014-01-07 12:52:07,358 INFO  [IoReceiver - /127.0.0.1:51065]
> (channel.close_forced) - [con:124(subscriber@/
> 127.0.0.1:51065/default)/ch:0] [con:124(subscriber@/
> 127.0.0.1:51065/default)/ch:0] CHN-1003 : Close : 405 - Cannot declare
> queue('subscriber:DurableTestSession'), as exclusive queue with same name
> declared on another session
> 2014-01-07 12:52:07,698 INFO  [IoReceiver - /127.0.0.1:51065]
> (connection.close) - [Broker] [con:124(subscriber@/127.0.0.1:51065/default)]
> CON-1002 : Close
>
>
> If I go into the web manager and delete the exchanges, queues, and
> sessions, I can run everything again successfully. I can also get a
> successful rerun if I bounce the server - which I’ve seen the unit tests
> also demonstrate. If something happens to the client and it needs to
> reconnect in a short period of time, it will fail to subscribe until Qpid
> releases the session.
>
> Based on this topic name, why would it be exclusive in the first place?
> test-topic / test-durable; {create: always, assert: never, node: { type:
> topic, durable: True, x-declare: { auto-delete: True, exclusive: False}}}
>
> Thanks in advance!
>
> -Logan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message