Hi Joseph,
Thanks for your answer,
On Tue, Jan 17, 2012 at 8:25 PM, Joseph Fialli <joe.fialli_at_oracle.com>wrote:
> **
> Andre,
>
> What version of shoal are you using? 1.5.x or the 1.6.x branch.
> I have committed fixes to the 1.6.x branch recently to enhance IPv6 support
> and to enhance selection of a IPv4 network interface, if one does exist.
> The submitted networkutility output looks like the 1.5.x branch (the
> trunk).
>
> Could you submit network utility output for 1.6.x branch?
>
My tests were made using the 1.6.17 version of Shoal (also for the version
of network utility used).
>
> Here is a pointer to that workspace:
> https://svn.java.net/svn/shoal~svn/branches/gms-transport-module
>
> Here is a pointer to the latest release (via maven):
>
> https://maven.java.net/content/repositories/public/org/shoal/shoal-gms-impl/1.6.17/shoal-gms-impl-1.6.17.jar
>
> You can run the latest 1.6.x NetworkUtility by downloading and including
> above jar in classpath.
>
> We have been working on gms-transport-module branch lately and it
> will become the trunk after glassfish 3.1.2 is released.
>
> ********
>
> Could you submit the entire logs?
>
Yep, they are attached.
>
> Or you could look for following at beginning of grupo:P1 server log.
>
> [#|2012-01-17T11:20:52.647-0500|CONFIG||ShoalLogger|_ThreadID=18;_ThreadName=Thread-4;|Grizzly
> controller listening on /0.0.0.0:9144. Controller started in 86 ms|#]
>
>
I've got this:
=========================
5473 [main] INFO ShoalLogger - Grizzly controller listening on null:9,129.
Transport started in 3 ms
==========================
At the first time, I've found this a little bit strange, however, I've
checked the log of an execution in a ipv4 only environment (where
everything works btw) and I've got the same "listening on null"
information. Anyway, maybe there is another information on the log that
should be useful to understand the problem.
>
> The above server log message states explicitly what address and port that
> grupo:P1 is listening on and could assist in understanding
> the error that you have sent in.
>
>
> java.io.IOException: failed to connect
> to fe80:0:0:0:862b:2bff:fe72:d5eb%3:9092:230.30.1.1:9090:grupo:P1
>
> ********
>
> Setting BIND_INTERFACE_ADDRESS is the means to specify a network interface
> when there are multiple ones and
> GMS is not selecting the correct one. There was support to set the
> network interface name but it was not
> working correctly on all platforms(linux was known to fail) due to
> differences in java.network methods across platforms.
> (Here is documentation of that known bug:
> http://java.net/jira/browse/GLASSFISH-18047)
>
> I do have a fix but was waiting for glassfish 3.1.2 to release before
> committing that fix.
> I have attached that diff if you would like to try out applying that patch
> yourself
> to latest revision of
> https://svn.java.net/svn/shoal~svn/branches/gms-transport-module.
>
> **********
>
Ok, I'll try it!
>
> I would like to state that our testing is mostly on IPv4 only or
> dual stack (IPv4 and IPv6). When we have tested on IPv6 only(very
> rarely), we have had to explicitly set
> several java.net properties (see link below)
>
> Link: http://docs.oracle.com/javase/7/docs/api/java/net/doc-files/net-properties.html
>
>
>
In this case should I modify the propertie java.net.preferIPv6Addresses?
> -Joe Fialli, Oracle Corp.
>
>
Thanks for your help!