org.jgroups.ChannelException: unable to setup the protocol stack

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

org.jgroups.ChannelException: unable to setup the protocol stack

Stuart Pook
My DNS is miss-configured and ping `hostname` doesn't work.  The error message that I get from jGroups 2.6.1 in this situation is misleading.  What happens is that Util.getBindAddress generates an exception caught in TP.setProperties.  This exception causes the reading of the properties in TP.setProperties to be aborted. The program continues but then dies later on because of the unread properties.

I would suggest not catching the exception if jGroups is going to die anyway.

I note that I called this program with resolve.dns=false but jGroups still calls InetAddress.getLocalHost() which does a dns lookup. I added bind_interface="eth0" to avoid the dns lookup but this is not perfect as the interface to use might not be called eth0.  How do I get jGroups to look at the list of interfaces and use the address of first one that is configured with multicast? It should be possible to do this without using the dns. Why doesn't jGroups call Util.getFirstNonLoopbackAddress instead of Util.getBindAddress in TP.setProperties and FD_SOCK.setProperties?

This is the printed error message:

% java -classpath ./lib/servlet-api-2.3.jar:./lib/logkit-1.0.1.jar:./lib/log4j-1.2.14.jar:./lib/jmxtools-1.2.8.jar:./lib/jmxremote-1.0.1_04.jar:./lib/jms-1.1.jar:./lib/jGroups-2.6.1.jar:./lib/commons-logging-1.1.jar:./lib/bsh-1.2b3.jar:./lib/avalon-framework-4.1.3.jar:./target/classes:./config -Dcom.sun.management.jmxremote -Dlog4j.configuration=file:./config/log4j.properties -Dresolve.dns=false com.xxxxx.tests.notification.Sender -props file:./config/udp.xml
org.jgroups.ChannelException: unable to setup the protocol stack
        at org.jgroups.JChannel.init(JChannel.java:1403)
        at org.jgroups.JChannel.<init>(JChannel.java:248)
        at org.jgroups.JChannel.<init>(JChannel.java:231)
        at com.etrali.tests.ChannelFactory.createChannel(ChannelFactory.java:28)
        at com.etrali.tests.notification.Sender.<init>(Sender.java:115)
        at com.etrali.tests.notification.Sender.main(Sender.java:108)
Caused by: java.lang.IllegalArgumentException: the following properties in UDP are not recognized: {oob_thread_pool.enabled=true, thread_pool.enabled=true, loopback=false, thread_pool.rejection_policy=Run, max_bundle_timeout=30, thread_pool.queue_max_size=1000, oob_thread_pool.min_threads=1, oob_thread_pool.keep_alive_time=5000, oob_thread_pool.rejection_policy=Run, thread_naming_pattern=cl, thread_pool.queue_enabled=true, enable_bundling=false, max_bundle_size=64000, thread_pool.max_threads=8, use_incoming_packet_handler=true, thread_pool.keep_alive_time=5000, oob_thread_pool.queue_max_size=100, discard_incompatible_packets=true, use_concurrent_stack=true, enable_diagnostics=true, oob_thread_pool.max_threads=8, oob_thread_pool.queue_enabled=false, thread_pool.min_threads=2}
        at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:701)
        at org.jgroups.stack.Configurator$ProtocolConfiguration.access$0(Configurator.java:665)
        at org.jgroups.stack.Configurator.createProtocols(Configurator.java:375)
        at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:58)
        at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:205)
        at org.jgroups.JChannel.init(JChannel.java:1400)
        ... 5 more

It is the log file that contains the real error message:

INFO  org.jgroups.JChannel  - JGroups version: 2.6.1
DEBUG org.jgroups.conf.ClassConfigurator  - mapping is:
1:      class org.jgroups.stack.IpAddress
2:      class org.jgroups.protocols.CAUSAL$CausalHeader
3:      class org.jgroups.protocols.FD$FdHeader
6:      class org.jgroups.protocols.FD_SOCK$FdHeader
7:      class org.jgroups.protocols.FragHeader
13:     class org.jgroups.protocols.PingHeader
14:     class org.jgroups.protocols.TcpHeader
19:     class org.jgroups.protocols.TunnelHeader
20:     class org.jgroups.protocols.UdpHeader
21:     class org.jgroups.protocols.UNICAST$UnicastHeader
22:     class org.jgroups.protocols.VERIFY_SUSPECT$VerifyHeader
24:     class org.jgroups.protocols.pbcast.GMS$GmsHeader
25:     class org.jgroups.protocols.pbcast.NakAckHeader
27:     class org.jgroups.protocols.pbcast.STABLE$StableHeader
28:     class org.jgroups.protocols.pbcast.STATE_TRANSFER$StateHeader
29:     class org.jgroups.protocols.SMACK$SmackHeader
30:     class org.jgroups.Message
31:     class org.jgroups.View
32:     class org.jgroups.ViewId
34:     interface org.jgroups.Address
35:     class org.jgroups.blocks.RequestCorrelator$Header
36:     class org.jgroups.protocols.PingRsp
38:     class java.util.Vector
39:     class org.jgroups.protocols.pbcast.JoinRsp
40:     class org.jgroups.util.Digest
41:     class java.util.Hashtable
53:     class org.jgroups.protocols.COMPRESS$CompressHeader
54:     class org.jgroups.protocols.FC$FcHeader
56:     class org.jgroups.protocols.TpHeader
57:     class org.jgroups.protocols.ENCRYPT$EncryptHeader
58:     class org.jgroups.protocols.SEQUENCER$SequencerHeader
59:     class org.jgroups.protocols.FD_SIMPLE$FdHeader
60:     class org.jgroups.protocols.VIEW_SYNC$ViewSyncHeader
61:     class org.jgroups.protocols.FD_ALL$Header
62:     class org.jgroups.protocols.SFC$Header

FATAL org.jgroups.protocols.UDP  - failed getting bind_addr
java.net.UnknownHostException: esterel: esterel
        at java.net.InetAddress.getLocalHost(InetAddress.java:1315)
        at org.jgroups.util.Util.getBindAddress(Util.java:2065)
        at org.jgroups.protocols.TP.setProperties(TP.java:619)
        at org.jgroups.protocols.UDP.setProperties(UDP.java:147)
        at org.jgroups.stack.Protocol.setPropertiesInternal(Protocol.java:95)
        at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:699)
        at org.jgroups.stack.Configurator$ProtocolConfiguration.access$0(Configurator.java:665)
        at org.jgroups.stack.Configurator.createProtocols(Configurator.java:375)
        at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:58)
        at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:205)
        at org.jgroups.JChannel.init(JChannel.java:1400)
        at org.jgroups.JChannel.<init>(JChannel.java:248)
        at org.jgroups.JChannel.<init>(JChannel.java:231)
        at com.etrali.tests.ChannelFactory.createChannel(ChannelFactory.java:28)
        at com.etrali.tests.notification.Sender.<init>(Sender.java:115)
        at com.etrali.tests.notification.Sender.main(Sender.java:108)
Reply | Threaded
Open this post in threaded view
|

Re: org.jgroups.ChannelException: unable to setup the protocol stack

Bela Ban


Stuart Pook wrote:
> My DNS is miss-configured and ping `hostname` doesn't work. The error
> message that I get from jGroups 2.6.1 in this situation is misleading.
> What
> happens is that Util.getBindAddress generates an exception caught in
> TP.setProperties.

It is actually caught in Util.getBindAddress(). I changed this in 2.7
and 2.6, so that the UnknownHostException is not caught anymore, but
propagated up the call stack, so setProperties will return false. This
in turn causes a runtime exception to occur on new JChannel(props).

Is this what you wanted ?

> This exception causes the reading of the properties in
> TP.setProperties to be aborted. The program continues but then dies
> later on
> because of the unread properties.
>
> I would suggest not catching the exception if jGroups is going to die
> anyway.

done

> I note that I called this program with resolve.dns=false but jGroups still
> calls InetAddress.getLocalHost() which does a dns lookup.

Yes, but only if you pass a symbolic host name, otherwise - with a
dotted decimal notation - only the validity is checked, no lookup is
performed. If you pass me a symbolic name, I *have* to convert it to an
InetAddress, this requires a lookup. Whether this is DNS, or /etc/hosts,
is up to you.



--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
javagroups-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Reply | Threaded
Open this post in threaded view
|

Re: org.jgroups.ChannelException: unable to setup the protocol stack

Stuart Pook
On Thu, January 10, 2008 09:56, Bela Ban wrote:

>> My DNS is miss-configured and ping `hostname` doesn't work. The error
>> message that I get from jGroups 2.6.1 in this situation is misleading.
>> What
>> happens is that Util.getBindAddress generates an exception caught in
>> TP.setProperties.
>
> It is actually caught in Util.getBindAddress(). I changed this in 2.7
> and 2.6, so that the UnknownHostException is not caught anymore, but
> propagated up the call stack, so setProperties will return false. This
> in turn causes a runtime exception to occur on new JChannel(props).
>
> Is this what you wanted ?

No.  If I understand the cvs revision of Util.java correctly, between 1.138 and 1.139
you no longer ignore the exception from the first call to InetAddress.getByName.  This
is not the exception we get.  We get an exception near the end of getBindAddress when
InetAddress.getLocalHost is called. This exception is not (and was not) caught in
Util.getBindAddress.

TP.setProperties catches this exception and returns false.  This is bad as the rest of
the properties are not read (nor removed) causing the program to die later on with a
difficult to understand error message.

>> This exception causes the reading of the properties in
>> TP.setProperties to be aborted. The program continues but then dies
>> later on
>> because of the unread properties.
>>
>> I would suggest not catching the exception if jGroups is going to die
>> anyway.
>
> done

No, if the call to Util.getBindAddress in TP.setProperties generates an exception,
TP.setProperties still returns false leaving the properties half read. I think that it
would be best not to catch the exception in TP.setProperties.

>> I note that I called this program with resolve.dns=false but jGroups still
>> calls InetAddress.getLocalHost() which does a dns lookup.
> Yes, but only if you pass a symbolic host name, otherwise - with a
> dotted decimal notation - only the validity is checked, no lookup is
> performed. If you pass me a symbolic name, I *have* to convert it to an
> InetAddress, this requires a lookup. Whether this is DNS, or /etc/hosts,
> is up to you.

No, I did not pass a symbolic name.  I didn't pass anything. As both bind_addr and
bind_interface are null jGroups calls InetAddress.getLocalHost().  This reads the value
of hostname and does a lookup of the result.  (On my miss-configured system this
generates an exception.)  I don't think that is this the best behavior. As you say if I
don't pass in a symbolic name JGroups should not do a name lookup.  In
Util.getBindAddress, if both bind_addr and bind_interface are null, JGroups should scan
the list of interfaces until it find one that is configured for multicast. Do you agree?

BTW, if seems to me that if bind_addr != null in Util.getBindAddress, then you call
InetAddress.getByName(bind_addr) twice.

Stuart



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
javagroups-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Reply | Threaded
Open this post in threaded view
|

Re: org.jgroups.ChannelException: unable to setup the protocol stack

Bela Ban
In TP.setProperties(), I return false if Util.getBindAddress(0 throws an
exception:
    try {
            bind_addr=Util.getBindAddress(props);
        }
        catch(UnknownHostException unknown) {
            log.fatal("failed getting bind_addr", unknown);
            return false;
        }
        catch(SocketException ex) {
            log.fatal("failed getting bind_addr", ex);
            return false;
        }

Returning false causes the ProtocolStack to throw an
IllegalArgumentException.

Okay, the exception message is not very clear, I changed this and
re-throw the exception in TP.setProperties() as an IllegalArgEx.

Stuart Pook wrote:

> On Thu, January 10, 2008 09:56, Bela Ban wrote:
>  
>>> My DNS is miss-configured and ping `hostname` doesn't work. The error
>>> message that I get from jGroups 2.6.1 in this situation is misleading.
>>> What
>>> happens is that Util.getBindAddress generates an exception caught in
>>> TP.setProperties.
>>>      
>> It is actually caught in Util.getBindAddress(). I changed this in 2.7
>> and 2.6, so that the UnknownHostException is not caught anymore, but
>> propagated up the call stack, so setProperties will return false. This
>> in turn causes a runtime exception to occur on new JChannel(props).
>>
>> Is this what you wanted ?
>>    
>
> No.  If I understand the cvs revision of Util.java correctly, between 1.138 and 1.139
> you no longer ignore the exception from the first call to InetAddress.getByName.  This
> is not the exception we get.  We get an exception near the end of getBindAddress when
> InetAddress.getLocalHost is called. This exception is not (and was not) caught in
> Util.getBindAddress.
>
> TP.setProperties catches this exception and returns false.  This is bad as the rest of
> the properties are not read (nor removed) causing the program to die later on with a
> difficult to understand error message.
>
>  
>>> This exception causes the reading of the properties in
>>> TP.setProperties to be aborted. The program continues but then dies
>>> later on
>>> because of the unread properties.
>>>
>>> I would suggest not catching the exception if jGroups is going to die
>>> anyway.
>>>      
>> done
>>    
>
> No, if the call to Util.getBindAddress in TP.setProperties generates an exception,
> TP.setProperties still returns false leaving the properties half read. I think that it
> would be best not to catch the exception in TP.setProperties.
>
>  
>>> I note that I called this program with resolve.dns=false but jGroups still
>>> calls InetAddress.getLocalHost() which does a dns lookup.
>>>      
>> Yes, but only if you pass a symbolic host name, otherwise - with a
>> dotted decimal notation - only the validity is checked, no lookup is
>> performed. If you pass me a symbolic name, I *have* to convert it to an
>> InetAddress, this requires a lookup. Whether this is DNS, or /etc/hosts,
>> is up to you.
>>    
>
> No, I did not pass a symbolic name.  I didn't pass anything. As both bind_addr and
> bind_interface are null jGroups calls InetAddress.getLocalHost().  This reads the value
> of hostname and does a lookup of the result.  (On my miss-configured system this
> generates an exception.)  I don't think that is this the best behavior. As you say if I
> don't pass in a symbolic name JGroups should not do a name lookup.  In
> Util.getBindAddress, if both bind_addr and bind_interface are null, JGroups should scan
> the list of interfaces until it find one that is configured for multicast. Do you agree?
>
> BTW, if seems to me that if bind_addr != null in Util.getBindAddress, then you call
> InetAddress.getByName(bind_addr) twice.
>
> Stuart
>
>
>
>  

--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
javagroups-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/javagroups-users