-
1. Re: HornetQConnectionFactory.setMaxConnections
jmesnil Oct 19, 2009 9:19 AM (in response to radimchatkalahari)I am not sure to understand what you're trying to achieve.
Concerning maxConnections, it has been removed from the trunk in https://jira.jboss.org/jira/browse/HORNETQ-162.
The JMS Connection is no longer multiplexed (there is now 1 remoting connection per JMS connection), the maxConnection setting is no longer used. -
2. Re: HornetQConnectionFactory.setMaxConnections
radimchatkalahari Oct 19, 2009 1:29 PM (in response to radimchatkalahari)Thank you for quick reply and clarification.
I've read HORNETQ-162, now I understand.
But my problem remains the same:
Messages (generated by producer) are received by consumer reordered.
(I observed this when I killed consumer a started a new one after a while,
newly started consumer received messages in wrong order - as I described in my first post.)
Is there any option (set for queue) how to guarantee receiving messages by consumer in the same order as they are produced by producer or this is not a goal
Thank you
Radimch -
3. Re: HornetQConnectionFactory.setMaxConnections
timfox Oct 19, 2009 1:36 PM (in response to radimchatkalahari)You should certainly not get messages delivered in the wrong order - if that occurs, it's a bug.
Can you file a JIRA with a test case and someone will fix it. -
4. Re: HornetQConnectionFactory.setMaxConnections
ataylor Oct 19, 2009 1:39 PM (in response to radimchatkalahari)Ok, so here's what is happening.
your first consumer starts consuming messages and at some point you kill it. Since consumers maintain an internal buffer for messages some of these messages are cancelled and put back on to the queue, if there were still messages in the queue at this point then these will be delivered first. This is as per the JMS spec. -
5. Re: HornetQConnectionFactory.setMaxConnections
radimchatkalahari Oct 20, 2009 3:37 AM (in response to radimchatkalahari)Thanks for replies.
How can I discover (from consumer's side) what messages has been canceled and returned back to queue?
Now I have run my test scenario for a couple of times, and (without code changes) messages did not reorder after client restart, but some messages arrived to consumer twice (duplicated) - probably those canceled.
If someone wants (and has time) to investigate, here are my simple tests:
http://radimch.net.tvtrinec.cz/java/messaging/hornetq/HornetQ_jmsConsumer.java
http://radimch.net.tvtrinec.cz/java/messaging/hornetq/HornetQ_jmsProducer.java
thanks
Radimch -
6. Re: HornetQConnectionFactory.setMaxConnections
timfox Oct 20, 2009 5:40 AM (in response to radimchatkalahari)Can you create a JIRA? Attach your test cases, and provide step-by-step instructions for how to replicate the issue?
Like Andy says, probably you are just killing the consumer, then immediately creating a new one, so the old consumer will stay alive until connection ttl at which point any buffered messages will return to the queue - this is completely normal and as per JMS spec.
(The JMS spec says the order of deliver is undefined when there is more than one consume on a queue. ) -
7. Re: HornetQConnectionFactory.setMaxConnections
jmesnil Oct 20, 2009 5:52 AM (in response to radimchatkalahari)"radimchatkalahari" wrote:
If someone wants (and has time) to investigate, here are my simple tests:
http://radimch.net.tvtrinec.cz/java/messaging/hornetq/HornetQ_jmsConsumer.java
http://radimch.net.tvtrinec.cz/java/messaging/hornetq/HornetQ_jmsProducer.java
Your consumer has a connection TTL of 10s.
Did you wait for more than 10s before creating a new consumer? -
8. Re: HornetQConnectionFactory.setMaxConnections
radimchatkalahari Oct 20, 2009 6:44 AM (in response to radimchatkalahari)Thanks for explanations,
I did not wait for 10 seconds before restarting consumer.
As I far as I understand now:
After first consumer shutdown I just need to wait for TTL (10 secs) and after that time start a new consumer.
Now it is clear for me.
Thank you for your patience.
Radimch -
10. Re: HornetQConnectionFactory.setMaxConnections
radimchatkalahari Oct 21, 2009 2:42 AM (in response to radimchatkalahari)Yes, I read the docs and I'm alway trying to close connections correctly.
But in this scenario I was testing network unreliability and how hornetq behaves when running in poor network connection conditions.
This is essential for me, since my apps are deployed in error-prone network environment (heavy industry).
Thank you for all your answers.