-
15. Re: JMS 2 Dev Thread
With regards to _JMSProducer_ and asynchronous sends due to _CompletionListener_.
As I understand our intention is to use of our own _ClientSession.setSendAcknowledgementHandler(..)_to support this.
The trouble (as I see it) is that:
- a producer must send messages in *synchronous* mode if _JMSProducer.setCompletionListener(null)_
- a producer must send messages in *asynchronous* mode if _JMSProducer.setCompletionListener(myCompletionListener)_ (i.e. the argument is not null)
- We can have multiple JMSProducer's created by a single JMSContext (which runs on top of a single HornetQSession)
- our SendAcknowledgementHandler is built on top of the session,
@Clebert, can you confirm that the spec intention is to have the completion-listener to affect the underlying session, or is it supposed to be really a per-producer setting?
-
16. Re: JMS 2 Dev Thread
as we talked it is per producer...
progress: I believe Temporary Queues only take one consumer into account. With the new spec you could have multiple consumers and the queue needs to be deleted as soon as the last consumer is closed. Look at createSharedSubscription (non durable on that case).
-
17. Re: JMS 2 Dev Thread
I'm changing temporary queues to use reference counting on deleting the queue. From this change on someone would be able to createTemoraryQueue any time.
If you did createTemporaryQueue("A1") 5 times... the queue will be only be deleted after its 5th time.
I have been thinking about creating a separate / parallel feature for that, such as sharedTemp, which will use the same schema of reference counting. For now I'm changing temporary queues to use the new semantic but I may come back into this concept and keep it separate....
will update here tomorrow.
-
18. Re: JMS 2 Dev Thread
It took me a while to figure out this but I got an Eureka now.
Temporary queues have to be untouched as their semantics on JMS require them to go away once the connection is gone.. regardless of the consumer's life cycle.
Shared subscriptions have to go away when all the consumers are gone. That's a different thing.
I have the shared subscription implemented on core at my branch. I will tomorrow move stuff over and I should have the shared subscription done shortly (early next week).
-
19. Re: JMS 2 Dev Thread
I just merged my CompletionListener work into "hornetq/jms2".
Two things left:
- we need to specify how we are going to support this when the user leaves ConfirmationWindowSize set to -1. Any opinions?
- also, I assume that passing a CompletionListener should override the values of blockOnPersistentSend and blockOnNonPersistentSend and that is not done yet.
-
20. Re: JMS 2 Dev Thread
1. as we talked, call complete and an one time warning.
2. I wouldn't do it synchronously. always async... that is correct. The only exception is with transactions.. I believe there are a few observations on the spec...
I think it's time we start looking at the TCK now. We should also write more of our own tests. I have looked today and I fixed a few. I'm starting to setup the environment on my own dev and I think we should all do the same, so we could run individual tests. I've spent some time today on downloading the stuff for it.
-
21. Re: JMS 2 Dev Thread
https://github.com/hornetq/hornetq/commit/4d0f9d7f33a70d3905113a05190b64ef4e93d117
Where did that come from? This is actually breaking a bunch of other JMS tests..
I didn't find any restrictions reading the docs...
Remember: Tests may be wrong and we may need to inform issues back to Oracle
For instance, our test RequestorJMSTest is failing, because javax.jms.QueueRequestor (which is an actual class) is actually doing exactly what you just forbid. I suspect this will break many other tests.
I want to understand exactly what you found as forbidden. Maybe it's something exclusively on the simplified API? However even on that front I didn't see anything on javadocs. Am I missing anything?
We will need to be careful when changing anything on the existent implementation. we have a bit more freedom on the simplified API and new methods.. but any change like this has to be confrontated by the docs.
-
22. Re: JMS 2 Dev Thread
as a reference from my last post, Francisco talked to me, and he believes the test in question was:
com/sun/ts/tests/jms/core20/appclient/messageproducertests/Client_topicUnsupportedOperationExceptionTests_from_appclient
-
23. Re: JMS 2 Dev Thread
I fixed it.. there was an issue with the default destination being checked what was a bug
-
24. Re: JMS 2 Dev Thread
Clebert Suconic wrote:
I fixed it.. there was an issue with the default destination being checked what was a bug
I don't understand what effectively changed at
https://github.com/clebertsuconic/hornetq/commit/81183f02784f787fdcde8715f9f0487f931f21a0
At the "added lines" +325 https://github.com/clebertsuconic/hornetq/commit/81183f02784f787fdcde8715f9f0487f931f21a0#L0R325
we still have the same test as we had before https://github.com/clebertsuconic/hornetq/commit/81183f02784f787fdcde8715f9f0487f931f21a0#L0L201
We are still checking for "if (destination != null && defaultDestination != null)". Funcionally we are no different than before as far as I can tell.
I understand we have loads of tests failing but the Javadoc at MessageProducer.send(Destination, Message) seem clear on the behavior:
@exception java.lang.UnsupportedOperationException
* if a client uses this method with a
* {@code MessageProducer} that specified a destination
* at creation time.
[...]
void send(Destination destination, Message message) throws JMSException
-
25. Re: JMS 2 Dev Thread
its clear in both 1.1 and 2.0 so its obviously our tests which i think we should fix