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
). 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@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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com