]
Tom Elrod updated JBREM-596:
-----------------------------
Fix Version/s: 2.2.0.Beta1 (Bluto)
Affects Version/s: 2.0.0.GA (Boon)
Lease doesn't work if client has two connections opened when
using callbacks
----------------------------------------------------------------------------
Key: JBREM-596
URL:
http://jira.jboss.com/jira/browse/JBREM-596
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: callbacks
Affects Versions: 2.0.0.GA (Boon)
Reporter: Clebert Suconic
Assigned To: Tom Elrod
Fix For: 2.2.0.Beta1 (Bluto)
If you have two connections, one of them is using CallBack the Lease is just stopped.
I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a
testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.
Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.
You can look at cruisecontrol results at this URL:
http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220...
and
http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220...
I have added a couple of messages on JBossRemoting code and I could see that with the
code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and
the lease thread never comes back.
Here is the code:
public void testSimplestDurableSubscription() throws Exception
{
ConnectionFactory cf =
(ConnectionFactory)ic.lookup("ConnectionFactory");
Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
Connection conn = cf.createConnection();
conn.setClientID("client1");
conn.start();
Connection conn2 = cf.createConnection();
conn2.setClientID("client2");
conn2.start();
Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);
MessageProducer prod = s.createProducer(topic);
prod.setDeliveryMode(DeliveryMode.PERSISTENT);
MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");
//conn2.close(); -- do not remote this comment. It was meant to not close the
connection
for (int i=0;i<10;i++)
{
prod.send(s.createTextMessage("k"+i));
}
s.commit();
conn.close();
conn = cf.createConnection();
conn.setClientID("client1");
conn.start();
s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
durable = s.createDurableSubscriber(topic, "subs1");
for (int i=0;i<2;i++)
{
TextMessage tm = (TextMessage)durable.receive(1000);
assertNotNull(tm);
s.commit();
System.out.println(tm.getText());
assertEquals("k" + i, tm.getText());
}
//conn.close();-- do not remote this comment. It was meant to not close the
connection
//System.exit(0); -- this is not needed as there is not tearDown, the client VM
will simply be finished the same way an exit would do, and this is better since it will
keep proper JUNIT report outputs
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: