Are you getting the session using the JMS RA??
> I hold the session open in a static library between
> publishing from a stateless session bean's remote
> method invocations (all methods marked as
If you are using JMS as a managed resource, don't do it this way. DONT DO IT THIS WAY. You allways have to be nice and close the session at methods end. It's pooled, for you.
I am getting the same Exception, but I am closing the Session. Just keeping open a connection to the Queue.
I am using JMS as a managed resource.
According to the JMS 1.02 Specification Section 4.4.11 & 4.4.12, ordering is only guaranteed within a destination's session.
If I close the session, how do I guarantee the order of the messages?
Am I misunderstanding the spec?
Is there another way to guarantee message ordering?
Thanks for your help.
Hi, I am sorry but I do not fully understand you. I thought you where publishing stuff only. What is the problem with the ordering?
Ordering is very important to our application. In our EJB 1.1 version of our product and our experience with other application servers (mostly Weblogic 5.x) we observed messages being received out of order (under heavy load). After much debugging, we tracked it down to the producers creating (and closing) a session every time a message was sent. The problem could be reproduced with 1 listener and many producers. When we re-examined the spec and changed the producers to cache the session (keyed on topic names), messages were always received in the correct order.
When we switched to Jboss (we just couldn’t take Weblogic’s high price, poor support, and just plain crappy software any more), we moved to an EJB 2.0 model. In addition, we switched to using JMS as a managed resource.
So this brings us back to how to guarantee message ordering when using JMS as a resource. We are not crazy about caching the session because of fail over and scaling issues, but if it’s the only way what other choices do we have?
Also, I so on another forum, someone claimed that message ordering could be guaranteed with persistent messages. I couldn’t find it where the spec mentions that, but I just might be missing it. Do you know if this is true?
How do you think we should proceed?
NovaPlex Technologies Inc.
Ok, when it commes to message ordering I am no expert. Maybe Hiram knows better how JBossMQ works under the hood here.
For JMS as a managed resource I am pretty shure that what you do is not spec compliant. My interpretation is generally that the Connector architecture only fitts with a session that is fetched and closed in every transactionall unit (most often a methodcall). It's been a while since I read the spec, but as far as I remember the connection manager do transaction handling when the client demand a connection (session for JMS) and only then can it really handle the transactionall stuff.
If I was you I would studdy the Connector spec to see if you cind of solution is realy part of a well behaving client according to that spec.
I don't think so, but I am fallible as most men are.
Thanks for your input. How do we direct the question/problem to Hiram?
I think peter is right. You should not be using the session that way.
You said that "The problem could be reproduced with 1 listener and many producers". The JMS spec states that message ordering is does not have to stay order accross multiple produces. Messages only need to be ordered relative to one producer.
Since you are caching the session, you have to keep in mind that the JMS spec states that a session object can only be used by one thread at a time. Beans can be called by many different threads. So this would be violating that rule. Yes, EJBs serialize access to the bean, but many different threads will have thier turn at it thus violating the JMS spec.
Since this is the case, you can get the same results and stay spec complient if you creating a new session object on each method call. All messages produced from that bean instance will be ordered since thread access is serialized and you commit after each method call.
The problem is when you have multiple bean instances, then you will multiple publishers publishing at the same time messing up message order. You need to restrict the number of bean instances to 1! I'm not sure how you would do this, but I think you may be able to use some of the JBoss Advance Container Configuration stuff to accomplish this (or do the method calls from an specific entity bean).
Ougth to be doable by setting the instance pool stuff:
Hiram and Peter,
Thanks for taking time to help me.
When I mentioned ‘1 listener and many producers’, I should have said beans that produce messages. With the architecture we have used in our EJB 1.1 application, all beans delegated message producing to a JMS manager class. The manager class cached a Session and it’s Publisher for every Topic name. In other words, (for publishing) each Topic had one Session with its associated Publisher cached. Again, we took this approach to solve the message-ordering problem.
I do not believe we violate the specification regarding multiple threads accessing the cached JMS Session. After re-reading sections 4.4 and 4.4.6, the sections seem to address the multiple thread issue with regards to listening and producing with the same session. If the session “defines the serial order for the messages it produces (section 4.4)”, what is wrong with having multiple threads publish messages? I guess as with all specs, it’s subject to reader interpretation. I agree with both of you, that we should not approach the solution by caching a managed resource. I am desperately looking for an alternative solution that provides correctness, performance, fail-over, scalability, and yet complies with J2EE standards.
Restricting the bean instances to 1, would adversely affect our performance and scalability. Some of the beans that produce the messages are entity beans. They transactionally produce messages when they are added/updated/deleted. This provides us behavior similar to that of a database trigger. I think you would agree, limiting an entity bean instance pool to a size of 1 essentially means table level locking. Most systems, including ours, simply could not provide any legitimate performance and scalability with a table level locking scheme.
Is there anything else you guys can recommend?
How do you address message ordering in your J2EE applications?
Again, thanks for taking time to help. I look forward to your replies.
NovaPlex Technologies, Inc.
hope you find a solution (please share it), I know of nothing more to help you, except saying that the J2EE integration of JMS may not be fully done at the spec level (remember, no message ordering is guaranteed for MDB).
> Hiram and Peter,
> Thanks for taking time to help me.
> When I mentioned ‘1 listener and many producers’, I
> should have said beans that produce messages. With
do you bean many beans or many bean instances???
> the architecture we have used in our EJB 1.1
> application, all beans delegated message producing to
> a JMS manager class. The manager class cached a
Is the JMS manager a SessionBean or a Singleton???
> Session and it’s Publisher for every Topic name. In
> other words, (for publishing) each Topic had one
> Session with its associated Publisher cached. Again,
> we took this approach to solve the message-ordering
Seems like the manager is singleton that hashes session by topic names. If mutilple bean instances are using the manager how do you garantee that only one thread ever uses the JMS session???
> I do not believe we violate the specification
> regarding multiple threads accessing the cached JMS
> Session. After re-reading sections 4.4 and 4.4.6,
How do you garantee that the only thread that uses a session is the thread the created the session??
> the sections seem to address the multiple thread
> issue with regards to listening and producing with
> the same session. If the session “defines the serial
> order for the messages it produces (section 4.4)”,
> what is wrong with having multiple threads publish
> messages? I guess as with all specs, it’s subject to
The problem is that a session is locked down to only being used by one thead. A the session is the one that determines the ordering of the messages. You are trying to get multiple thread to share 1 sessions publisher which is a no-no. (Per spec.)
> reader interpretation. I agree with both of you,
No, the multiple thread trying to use one session is not open to interpretation. It's in bold print somewhere in the spec :)
PS... how do you know messages are arriving out of order?? Do you use a counter to number them or something???
Sorry I haven't responded, as I was out of town.
Anyway, as you suspected, our JMS Manager is a singleton.
>The problem is that a session is locked down to only being used by one thead. A the session is the one that >determines the ordering of the messages. You are trying to get multiple thread to share 1 sessions >publisher which >is a no-no. (Per spec.)
According to section 4.6, it's the producer of the session that dictates the ordering of the messages:
"Each time a client creates a MesssageProducer, it defines a new sequence of messages that have no ordering relationship with the messages it has previously sent."
If the producer of a session dictates the ordering, how would you guarantee ordering without using the same publisher for a given topic?
>No, the multiple thread trying to use one session is not open to interpretation. It's in bold print somewhere in the >spec :)
I have re-read the spec again. To be honest, I can't even find anything that is in bold print that refers to sessions. Could you direct me to section and paragraph of the spec to which you are refering?
Also, Section 4.4 states (in a footnote): "There are no restrictions on the number of threads that can use a Session object or those it creates."
>PS... how do you know messages are arriving out of order?? Do you use a counter to number them or something???
We discovered the problem using Weblogic 5.x. Their JMS implementation used synchronous IDs. So after experiencing strange behavior (under heavy load), we began recording the order the IDs were coming in. So, this lead us to read and re-read the spec to see if it was us or the vendor. So now we are trying to stay portable and compliant with the spec.
Hiram, if you must open and close a session for each transaction, how would you address guaranteed ordering of messages?