Re: [javagroups-users] IllegalArgumentException in UNICAST
Brought to you by:
belaban
From: Bela B. <be...@ya...> - 2007-07-26 15:45:58
|
No, don't file a bug, there is already one (http://jira.jboss.com/jira/browse/JGRP-564). You can subscribe to that one to get emails when it is updated/resolved. I'm waiting for Vladimir to get back to me to discuss whether we can safely swap lines 505 and 506. Lenny Phan wrote: > Hi Bela, > > Alternative #1 and #2 doesn't really apply to my situation as we're > attempting to send a message to a new > member in response to a new View message. > > I will try sending the ENABLE_UNICASTS_TO event (with the new > destination) down the stack before sending my message > and it looks like it should work (from looking at the code). > > Given that this seems to be a race condition, should a bug be filed for > tracking an alternative fix? > > Thanks! > > --Lenny > > Bela Ban wrote: > >> Lenny Phan wrote: >> >>> Thanks! The scenario described below is exactly what's >>> intermittently happening. >>> I'm not sure I understand how alternatives #1 and #2 might work for >>> this race condition? >>> >> #1 When connect() returned, we are guaranteed that the view has been >> received up and down the stack, including UNICAST. UNICAST updates its >> membership, so the issue you're seeing won't happen. >> >> You could also send down an event Event.ENABLE_UNICASTS_TO (with the >> unicast destination you want to send to), this would prevent UNICAST >> from throwing the exception when sending a message to a dest T which >> is (not yet) in the membership list. >> >> >>> Bela Ban wrote: >>> >>>> No. It could still happen, though less likely. Since pass the view >>>> up the stack first, then down, if the view was placed onto the queue >>>> and processed *before* we send the view down (and thus update >>>> UNICAST's membership), you'd still see the same issue. >>>> >>>> The offending code is at GMS.java (ll 505-506): >>>> >>>> 502 // Send VIEW_CHANGE event up and down the stack: >>>> 503 Event view_event=new Event(Event.VIEW_CHANGE, >>>> new_view.clone()); >>>> 504 // changed order of passing view up and down >>>> (http://jira.jboss.com/jira/browse/JGRP-347) >>>> 505 up_prot.up(view_event); >>>> 506 down_prot.down(view_event); // needed e.g. by failure >>>> detector or UDP >>>> >>>> Line 505 passes the event up the stack, 506 down the stack. If we >>>> swap the lines, your code will be fine. However, Vladimir swapped >>>> them before, to fix JGRP-347. I've pinged him to find out the reason >>>> why he did that. If it turns out we can swap those lines back, your >>>> code is guaranteed to work, otherwise we'll have to look at >>>> alternatives. >>>> >>>> Some alternatives that come to mind: >>>> >>>> #1 Set a flag to true once JChannel.connect() has returned >>>> #2 Implement the ChannelListener.channelConnected() callback >>>> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > javagroups-users mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/javagroups-users > > -- Bela Ban Lead JGroups / JBoss Clustering team JBoss - a division of Red Hat |