[ 
https://issues.apache.org/jira/browse/QPID-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Logan Barnett updated QPID-5453:
--------------------------------

    Description: 
Attached is a program that creates a durable topic subscription, disconnects, 
publishes a message, and then re-subscribes.

When running the program, it completes receives the message sent while the 
subscriber was disconnected. No surprise there. When running the program a 
second time, the session.createDurableSubscriber call stalls for a while. 
Eventually it times out with this message:
{noformat}
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]
{noformat}

On the server side, this is what I get during a failing run:
{noformat}
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
{noformat}

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?
{noformat}
test-topic / test-durable; {create: always, assert: never, node: { type: topic, 
durable: True, x-declare: { auto-delete: True, exclusive: False}}}
{noformat}

  was:
Attached is a program that creates a durable topic subscription, disconnects, 
publishes a message, and then re-subscribes.

When running the program, it completes receives the message sent while the 
subscriber was disconnected. No surprise there. When running the program a 
second time, 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:
{panel}
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
{panel}

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?
{panel}
test-topic / test-durable; {create: always, assert: never, node: { type: topic, 
durable: True, x-declare: { auto-delete: True, exclusive: False}}}
{panel}


> Subscription sessions linger
> ----------------------------
>
>                 Key: QPID-5453
>                 URL: https://issues.apache.org/jira/browse/QPID-5453
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: 0.24
>            Reporter: Logan Barnett
>         Attachments: Hello.java
>
>
> Attached is a program that creates a durable topic subscription, disconnects, 
> publishes a message, and then re-subscribes.
> When running the program, it completes receives the message sent while the 
> subscriber was disconnected. No surprise there. When running the program a 
> second time, the session.createDurableSubscriber call stalls for a while. 
> Eventually it times out with this message:
> {noformat}
> 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]
> {noformat}
> On the server side, this is what I get during a failing run:
> {noformat}
> 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
> {noformat}
> 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?
> {noformat}
> test-topic / test-durable; {create: always, assert: never, node: { type: 
> topic, durable: True, x-declare: { auto-delete: True, exclusive: False}}}
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to