Invalid JORAM Test

[clebert.suconic]

On the integration testsuite from JBossAS (trunk) which I'm moving to Branch_4_x, there is one invalid JORAM Test, which is doing something like this:

 public void testStopStartConnection() throws Exception
 {
 Queue queue = (Queue)ic.lookup("/queue/TestQueue");
 Queue receiverQueue = (Queue)ic.lookup("/queue/TestQueue");

 QueueConnectionFactory qcf = (QueueConnectionFactory)cf;

 QueueConnection connProducer = qcf.createQueueConnection();
 QueueSession senderSession = connProducer.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE);
 QueueSender sender = senderSession.createSender(queue);

 QueueConnection receiverConnection = qcf.createQueueConnection();
 QueueSession receiverSession = receiverConnection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE);
 QueueReceiver receiver = receiverSession.createReceiver(receiverQueue);

 connProducer.start();
 receiverConnection.start();


 receiverConnection.stop();
 receiverSession = receiverConnection.createQueueSession(false, Session.CLIENT_ACKNOWLEDGE);
 // receiver.close(); /// This would fix the test
 receiver = receiverSession.createReceiver(receiverQueue);
 receiverConnection.start();


 Message message = senderSession.createMessage();
 sender.send(message);

 Message m = receiver.receive(30000);


 m.acknowledge();
 }

(The above is a simplification of what was happening on the JORAM test.. since it was playing with setup, and opening the receivers again on the test itself)

The test creates a receiver... and later creates the receiver again without closing the previous one.

I don't know if this is legal on JORAM, but it is certainly not legal on JBossMessaging. You are required to clear the previous receiver before assign a new one on the same queue, because of that I will be changing the JORAM test accordingly. (Unless anyone has anything against the change)


Clebert

[clebert.suconic]

The test I'm changing is org.objectweb.jtests.jms.conform.connection.ConnectionTest::testAcknowledge at our CVS repository.

[timfox]

I don't know if this is legal on JORAM, but it is certainly not legal on JBossMessaging. You are required to clear the previous receiver before assign a new one on the same queue, because of that I will be changing the JORAM test accordingly. (Unless anyone has anything against the change)
Clebert

Actually, it's perfectly legal to create more than one receiver on the same queue.

It's just that it's not specified in the JMS spec which receiver would get the message.

In the case of JBM they would be round-robined.

However, if the test is expecting the the latest receiver to get the message, then I accept the test is probably flawed.

[clebert.suconic]

"timfox" wrote:

I don't know if this is legal on JORAM, but it is certainly not legal on JBossMessaging. You are required to clear the previous receiver before assign a new one on the same queue, because of that I will be changing the JORAM test accordingly. (Unless anyone has anything against the change)
Clebert

Actually, it's perfectly legal to create more than one receiver on the same queue.

It's just that it's not specified in the JMS spec which receiver would get the message.

In the case of JBM they would be round-robined.

However, if the test is expecting the the latest receiver to get the message, then I accept the test is probably flawed.

Yep.. that's what I meant... but I think it's odd the test was passing on JORAM (originally written to) and JBossMQ.

[clebert.suconic]

Another JORAM Test is failing.. but this time I think it's a bug:


I have written a similar test to testSetClientID on ConnectionTest...

public void testSetClientID2() throws Exception
 {
 Connection connection = cf.createConnection();
 if (connection.getClientID() == null)
 {
 connection.setClientID("publisherConnection");
 }

 connection.close();
 }

This is throwing "javax.jms.IllegalStateException: setClientID can only be called directly after the connection is created"

Testing for set ClientID is making something dirty.. so we can't setClientID...


http://jira.jboss.org/jira/browse/JBMESSAGING-995

[timfox]

I would say the JORAM test is invalid.

setClientID() is supposed to throw an exception unless it is the first operation called on the connection.

In your case, you are calling getClientID() first, so it is correct to throw an exception:

See http://java.sun.com/j2ee/1.4/docs/api/index.html

[timfox]

BTW - you should inform the JORAM guys about the invalid tests so they can correct them.

[clebert.suconic]

"timfox" wrote:
I would say the JORAM test is invalid.

setClientID() is supposed to throw an exception unless it is the first operation called on the connection.

In your case, you are calling getClientID() first, so it is correct to throw an exception:

See http://java.sun.com/j2ee/1.4/docs/api/index.html

Well... I wouldn't consider checking for getClientID an operation... JORAMTests aways tests if ClientID is already set... if not set by the provider it would set the ClientID.

I would agree about that on real operations.. but not on getClientID.

Ah... BTW... connection.start() is not setting the just created..

The following tests would fail:

public void testSetClientAfterStart()
 {
 try
 {
 Connection connection = cf.createConnection();

 //we start the connection
 connection.start();

 // an attempt to set the client ID now should throw a IllegalStateException
 connection.setClientID("testSetClientID_2");
 fail("Should throw a javax.jms.IllegalStateException");
 }
 catch (javax.jms.IllegalStateException e)
 {
 }
 catch (JMSException e)
 {
 fail("Should raise a javax.jms.IllegalStateException, not a " + e);
 }
 catch (java.lang.IllegalStateException e)
 {
 fail("Should raise a javax.jms.IllegalStateException, not a java.lang.IllegalStateException");
 }

 }

[timfox]

Well... I wouldn't consider checking for getClientID an operation...

The JMS javadoc talks about actions on the connection:

"If a client sets the client identifier explicitly, it must do so immediately after it creates the connection and before any other action on the connection is taken. After this point, setting the client identifier is a programming error that should throw an IllegalStateException."

getClientID() is certainly an action on the connection, I don't think you can argue it is not.

Therefore it seems pretty clear to me the JORAM test is invalid

Ah... BTW... connection.start() is not setting the just created..

Well, that would be a different problem. The fix is trivial for that though.

[clebert.suconic]

Well, that would be a different problem. The fix is trivial for that though.

Yep.. it is. And it's already fixed on my env.


I will remove the other test as you think it's invalid.

[clebert.suconic]

getClientID() is certainly an action on the connection

Well.. I still think it's not an action, as the Connection would stay the same after that operaion... It's like a get property... nothing is changed... like nothing happened.

But I don't want to arguee about that, as I don't really mind... I will just comment out those ClientID tests.

[timfox]

Actions don't have to change the state of the object they are acting on.

E.g. asking what the time is, is an action but it does not change the state of the clock.

Saying nothing is changed, is *absolutely* not the same as saying nothing happened.

When I ask the time, or measure someone's height, then absolutely something happened (the thing that happened was that I measure their height and it gave useful information), but me measuring their height doesn't make their height change.

If your definition of an action is "something that changes the state of the object", then what would you call "something that does not change the state of the object".

[clebert.suconic]

If your definition of an action is "something that changes the state of the object", then what would you call "something that does not change the state of the object".

A read only action :-)

Well.. as I said.. I don't mind if we change it or not...

For me it was just a sign that JBossMQ and JORAM implemented this way.

[timfox]

A read only action :-)

.

That would be contradictory.

If we take your previous definition of "action" as "something that changes state".

Then "read only action" would expand as "a read-only something that changes state" which clearly makes no sense.

So you need to come up with another definition. ;)

Alternatively we could just forget it and do something useful?

[clebert.suconic]

Alternatively we could just forget it and do something useful?

I could go on with this discussion a little further... (LOL)

But lets do something useful!