[jboss-dev] Flush failed is back in jgroups

[Brian Stansberry]

org.jboss.Main sets the jgroups.bind_addr system property to 127.0.0.1 
by default. (I think you did that. ;))

There have been some changes in the way JGroups creates sockets (to 
avoid around the problem discussed at 
http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic).  I'll have 
a look to see if somehow that's causing the jgroups.bind_addr setting to 
be bypassed.

Adrian Brock wrote:
> The current jgroups is trying to send udp requests over by nic 
> (which doesn't work because it isn't up).
> 
> It should be bound to only "localhost" by default.
> 
> On Tue, 2008-03-18 at 17:18 -0500, Brian Stansberry wrote:
>> Adrian: Is multicast working on your loopback interface?  The problems 
>> are symptoms of the channel not receiving back its own messages.
>>
>> I'm going to change the AS's JGroups configs to loopback their own 
>> messages to themselves rather than relying on getting them back from the 
>> network.  http://jira.jboss.com/jira/browse/JBAS-5323  That will make 
>> this strange behavior go away (although the node of course will not be 
>> able to communicate with other nodes).
>>
>> Clebert: the NPE here is because with multicast not working, the 
>> MuxChannel is not connecting correctly. So you don't get the view. It's 
>> basically a broken channel; IMO connect() should not have returned 
>> properly but rather a ChannelException should have been thrown. This is 
>> an example of why we want to move away from the multiplexer and toward 
>> shared transport channels. The code that prevented the view being 
>> received is part of the multiplexer layer that will no longer be used in 
>> the AS.
>>
>> Clebert Suconic wrote:
>>>  >
>>>  > I notice the NPE still exists in JBoss Messaging as well.
>>>
>>>
>>> I believe the NPE solved you're mentioning is another NPE, in another case.
>>>
>>>
>>> I am currently dealing with this exception in our testsuite, as we are 
>>> updating JGroups at our development branch. (STABLE)
>>>
>>> There is some race condition between channel.connect() and when the View 
>>> is sent. With JGroups 2.4, and the stack we are using at JBM, the view 
>>> would aways be sent while channel.connect() is called (synchronized). It 
>>> looks like this has changed on 2.6. (Probably another thread sending the 
>>> view... or the Stack is different).
>>>
>>> On my tests I assumed this was because we didn't have the flush 
>>> protocol, but i can see that Flush is being used at the Multiplexor 
>>> channels.
>>>
>>> I am doing some debug right now, and I will update it as soon as we have 
>>> solved this.
>>>
>>>
>>> Clebert
>>>
>>> Adrian Brock wrote:
>>>> I thought this had been fixed?
>>>>
>>>> I notice the NPE still exists in JBoss Messaging as well.
>>>>
>>>>
>>>> 13:47:12,943 INFO  [STDOUT] 
>>>> -------------------------------------------------------
>>>> GMS: address is 127.0.0.1:32774
>>>> -------------------------------------------------------
>>>> 13:47:27,515 WARN  [MuxChannel] Flush failed at
>>>> 127.0.0.1:32774:DefaultPartition-JMS-CTRL
>>>> 13:47:29,519 WARN  [Multiplexer] failed to collect all service ACKs (1)
>>>> for [dst: <null>, src: 127.0.0.1:32774 (4 headers), size=0 bytes] after
>>>> 2000ms, missing ACKs from [127.0.0.1:32774] (received=[]),
>>>> local_addr=127.0.0.1:32774
>>>> 13:47:34,520 WARN  [JChannel] Timeout waiting for UNBLOCK event at
>>>> 127.0.0.1:32774
>>>> 13:47:34,525 ERROR [ExceptionUtil]
>>>> org.jboss.messaging.core.jmx.MessagingPostOfficeService at 197e6dc
>>>> startService
>>>> java.lang.NullPointerException
>>>>         at
>>>> org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:160) 
>>>>
>>>>         at
>>>> org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:347) 
>>>>
>>>>         at
>>>> org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:427) 
>>>>
>>>>         at
>>>> org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299) 
>>>>
>>>>         at
>>>> org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
>>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com