BTW a nice way to clean up dead conversations could just be to time them out.
On the Lingo project we have a useful Map implementation class which if the key is not used within a time window its evicted from RAM; we could maybe use this with the SimpleMessageGroupMap to clean up conversations after a period of inactivity. http://lingo.codehaus.org/maven/apidocs/org/logicblaze/lingo/util/TimeoutMap.html On 6/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
LOL. No worries - I was being lazy too not showing you how to do it :). Still glad to hear it was possible for you to figure it out :) On 6/21/06, Sanjiv Jivan <[EMAIL PROTECTED]> wrote: > On 6/21/06, Sanjiv Jivan <[EMAIL PROTECTED]> wrote: > > > > > > > > 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 ? > > > > > > I'll figure this out. Kinda late here and I was getting lazy to dig through > the source now.. Sorry :) > > 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/ > > > > > > > > > > > -- James ------- http://radio.weblogs.com/0112098/
-- James ------- http://radio.weblogs.com/0112098/
