Ops, just remembered that I didn't attached the network utility outputs.
On Wed, Jan 18, 2012 at 11:11 AM, André Fonseca <
andre.amorimfonseca_at_gmail.com> wrote:
> 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!
>