On 6/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
BTW what do you do if the JVM running the conversation dies?
If the JVM running the conversation dies, the message group for this
converation should fail over to another server where an exception will be
raised indicating that the conversation is not recognized on this server.
The client will see this exception message and can then restart the
conversation against a new server.
It sounds like then if you don't want to close a message group (for
fear of closing another message group) then you could consider
(i) using an alternative MessageGroupMap implementation which doesn't
use hash buckets - this could use lots more RAM if you have a large
number of JMSXGroupID values - and there is the chance of a memory
leak if you keep generating values and don't close them down but you
may be happy to pay that cost
http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/broker/region/group/MessageGroupMap.html
i.e. use the SimpleMessageGroupMap rather than the default which uses
hash buckets.
(ii) to close a conversation, just close the message consumer.
Maybe you need (i)?
Yes, SimpleMessageGroupMap seems like what I need. In my usecase there will
not be many conversations (50 atmost) and I will be able to write a cleanup
routine to close dead conversations.
Is there a top level factory/property I can set using the Spring config
(like the connection factory or the destination) to cause it internally use
SimpleMessageGroupMap ?
Thanks,
Sanjiv
On 6/20/06, Sanjiv Jivan <[EMAIL PROTECTED]> wrote:
> On 6/20/06, James Strachan <[EMAIL PROTECTED]> wrote:
> >
> > On 6/20/06, Thomas Swindells <[EMAIL PROTECTED]> wrote:
> > > James.Strachan wrote:
> > > >
> > > > On 6/19/06, Sanjiv Jivan <[EMAIL PROTECTED]> wrote:
> > > >> > 2. Is there a way to detach a message group affinity to a
> > particular
> > > >> broker.
> > > >>
> > > >> >Just set JMSXGroupSeq to zero on the last message which 'closes'
the
> > > >> >message group so if another message is sent in the future with
the
> > > >> >same group ID it will be reassigned to a new consumer.
> > > >>
> > > >> >message.setIntProperty("JMSXGroupSeq", 0);
> > > >>
> > > >> This would reset all the affinity of all the message groups,
right?
> > > >
> > > > No - just the message group for the JMSXGroupId setting.
> > > > I should have been more clear... to clear message group FOO use
> > > >
> > > > message.setStringProperty("JMSXGroupID", "FOO");
> > > > message.setIntProperty("JMSXGroupSeq", 0);
> > > >
> > > Reading the Message group page
> > > (http://activemq.org/site/message-groups.html) there is probably a
minor
> > bug
> > > here in that it would close all messsage groups with the same Hash
as
> > "FOO",
> > > although in practice for a well designed system expecting that msg
> > groups
> > > could change this shouldn't be a problem. Of course the chances of a
> > hash
> > > clash for relatively short group id's is pretty tiny.
> >
> > Yeah - hashing collisions should be fairly unlikely - though its a RAM
> > v risk tradeoff - the larger the number of hash buckets, the more RAM
> > used but the less likely a collision.
> >
> > Though worse case a message group is closed and reopened - which just
> > rebalances the association of message groups to consumers so it
> > doesn't cause much harm (*).
>
>
> This would cause harm if a message group is used as a basis of a
stateful
> conversation with the chosen server (which embeds a broker)which I how I
> require to use them in my usecase. Is not like a stateless stock quote
> request which any server can respond to.. its more like
> startConversation(A), getResults(A) and if getResults(A) goes to the
wrong
> server, its an error condition since the conversation was started with
> another server. I do not want to get in the business of state
replicating
> servers, just want to partition conversation based load based (rather
that
> individual request based load balancing).
>
>
--
James
-------
http://radio.weblogs.com/0112098/
