The behaviour you describe in both situations is obviously not desired but
it is all that is implemented in JBossMQ at this time ( I know this because
I wrote it ).  In other words the problems you are seeing are not brought
about by your lack of understanding or a "bug" as such, it simply
implemented that way.

When you raised the first point I had a look at the source and unfortunately
there is no 5 minute fix to either problem.  The solution needs some
thought, a little coding and quite a bit of testing and I am no longer able
to do this myself.  In my earlier reply (trying to be helpful) I made a
couple of suggestions for an approach I think will solve the problem.

I strongly suggest you either look at these problems yourself and supply a
patch for them or enter them as bugs at sourceforge, that way one of the
core team will be more likely to look at them and try to solve the problem.

Oh yeah, if (when you don't commit) you actually rollback the session the
message will become available for redelivery.  In other words don't just
terminate your client (if you can avoid it) but always commit or rollback
your session.  I think simply closing the session will also work as this
will rollback any uncommitted transactions.  The case JBossMQ doesn't handle
well is when the client simply crashes and goes away without cleaning up.

I hope this helps.

David

> -----Original Message-----
> From: Joshua D. Cough [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 6:56 AM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] JMS Explanation Needed
> 
> 
> Could someone please explain to me the default behavior in 
> the following
> scenario?
> 
> I create a transacted Session, receive a single message from 
> a Queue, I DONT
> COMMIT, and I terminate my client. 
> 
> That message remains in the Queue, but cannot be received by any other
> Session.
> 
> If I restart JBOSS, the message can then be received by some 
> other Session.
> 
> Is this what is supposed to happen? Is there any way that I 
> can receive that
> Message again in a different Session without having to restart JBOSS?
> and/or, is this a bug?
> 
> The same situation exists if I fail to call acknowledge from a non
> transacted session.
> --------------------------------------------------------------------
> 
> I am the same person who sent out the bug saying that 
> session.recover()
> calls session.rollback() even though it cannot do that due to the if
> statements that are set up in each method. No one has had a 
> chance to fix
> that bug yet. 
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.371 / Virus Database: 206 - Release Date: 6/13/2002
 


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to