activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Questions / issue with CLIENT_ACK mode.
Date Mon, 10 Apr 2006 23:57:38 GMT
Hi,

The spec prohibits that (see section 2.8).  Sessions, consumers, and
producers should only be access by a single logical thread.  They
further explain this restriction as follows:

<quote>
There are two reasons for restricting concurrent access to Sessions. First,
Sessions are the JMS entity that supports transactions. It is very difficult to
implement transactions that are multithreaded. Second, Sessions support
asynchronous message consumption. It is important that JMS not require that
client code used for asynchronous message consumption be capable of
handling multiple, concurrent messages. In addition, if a Session has been set
up with multiple, asynchronous consumers, it is important that the client is not
forced to handle the case where these separate consumers are concurrently
executing. These restrictions make JMS easier to use for typical clients. More
sophisticated clients can get the concurrency they desire by using multiple
sessions.
</quote>


On 4/10/06, yaussy <yaussy@cboe.com> wrote:
>
> Looking at the JMS spec, I'm not seeing anything yet that directly prohibits
> a durable Message object, coming in on a TopicSession which is set to
> CLIENT_ACKNOWLEDGE, from being passed on to another thread for processing
> (and later acknowledgement on that thread).
>
> So, my question is: is this explicitly prohibited?
>
> If not, it seems like this is not allowed for in ActiveMQMessageConsumer.
> The deliveredMessages linked list is not protected for this type of usage
> scenario.  The list can be cleared concurrently with new messages being
> added, thus causing NullPointer exceptions.
> --
> View this message in context: http://www.nabble.com/Questions-issue-with-CLIENT_ACK-mode.-t1427632.html#a3850173
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>


--
Regards,
Hiram

Mime
View raw message