8:14 a.m.
Hi,
Re: https://issues.jboss.org/browse/ISPN-8186
I've been looking at TRACE logs and what seems to happen is that is that sometimes,
when the client needs to create a new Socket, it sends using the same localport as the Hot
Rod server port. As a result, when the client sends something to the server, it also
receives it, hence it ends finding a request instead of a response. Analysis of the logs
linked in the JIRA can be found in [1].
What I'm not sure about is how to fix this... There are ways to potentially pass a
specific localport to a Socket [2] but this could be a bit messy: It'd require us to
generate a random local port and see if that works, making sure that's not the server
port...
However, I think the real problem we're having here is the fact that both the server
and client are bound to same IP address, 127.0.0.1. A simpler solution could be a way to
get the server to be in a different IP address to the client, but what would that be that
IP address and how to make sure it always works? Bind the server to eth0?
Any other ideas?
Cheers,
[1] https://gist.github.com/galderz/b8549259ff65cb74505c9268eeec96a7
[2]
http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html#Socket(java...
--
Galder Zamarreño
Infinispan, Red Hat
9:30 a.m.
On 11 August 2017 at 14:14, Galder Zamarreño <galder(a)redhat.com> wrote:
Hi,
Re: https://issues.jboss.org/browse/ISPN-8186
I've been looking at TRACE logs and what seems to happen is that is that sometimes,
when the client needs to create a new Socket, it sends using the same localport as the Hot
Rod server port. As a result, when the client sends something to the server, it also
receives it, hence it ends finding a request instead of a response. Analysis of the logs
linked in the JIRA can be found in [1].
What I'm not sure about is how to fix this... There are ways to potentially pass a
specific localport to a Socket [2] but this could be a bit messy: It'd require us to
generate a random local port and see if that works, making sure that's not the server
port...
However, I think the real problem we're having here is the fact that both the server
and client are bound to same IP address, 127.0.0.1. A simpler solution could be a way to
get the server to be in a different IP address to the client, but what would that be that
IP address and how to make sure it always works? Bind the server to eth0?
Any other ideas?
You could create multiple aliases for the same loopback device, and
assign a different IP address to each of them.
But I fail to understand why you don't have specific ports for each
purpose? That's the point for using ports in the first place, no?
Thanks,
Sanne
Cheers,
[1] https://gist.github.com/galderz/b8549259ff65cb74505c9268eeec96a7
[2]
http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html#Socket(java...
--
Galder Zamarreño
Infinispan, Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:48 a.m.
On Fri, Aug 11, 2017 at 3:30 PM, Sanne Grinovero <sanne(a)infinispan.org>
wrote:
On 11 August 2017 at 14:14, Galder Zamarreño
<galder(a)redhat.com> wrote:
> Hi,
>
> Re: https://issues.jboss.org/browse/ISPN-8186
>
> I've been looking at TRACE logs and what seems to happen is that is that
sometimes, when the client needs to create a new Socket, it sends using the
same localport as the Hot Rod server port. As a result, when the client
sends something to the server, it also receives it, hence it ends finding a
request instead of a response. Analysis of the logs linked in the JIRA can
be found in [1].
>
> What I'm not sure about is how to fix this... There are ways to
potentially pass a specific localport to a Socket [2] but this could be a
bit messy: It'd require us to generate a random local port and see if that
works, making sure that's not the server port...
>
> However, I think the real problem we're having here is the fact that
both the server and client are bound to same IP address, 127.0.0.1. A
simpler solution could be a way to get the server to be in a different IP
address to the client, but what would that be that IP address and how to
make sure it always works? Bind the server to eth0?
>
> Any other ideas?
You could create multiple aliases for the same loopback device, and
assign a different IP address to each of them.
No need for aliases, we could use directly use any IP from the range
127.0.0.0/8
Just a reminder, the testsuite should be able to run on Linux/Win/MacOS so
I'd stay
away for OS specific extra steps
But I fail to understand why you don't have specific ports for each
purpose? That's the point for using ports in the first place, no?
The issue is the suite runs 15 tests in parallel, with each test starting
potentially more than 1 server;
the client(s) obtains the server port(s) dynamically and start a
connection, but with bad luck the client's
localport happens to be the same as the server random port.
Thanks,
Sanne
>
> Cheers,
>
> [1] https://gist.github.com/galderz/b8549259ff65cb74505c9268eeec96a7
> [2] http://docs.oracle.com/javase/6/docs/api/java/net/Socket.
html#Socket(java.net.InetAddress,%20int,%20java.net.InetAddress,%20int)
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:07 p.m.
On Fri, Aug 11, 2017 at 5:48 PM, Gustavo Fernandes <gustavo(a)infinispan.org>
wrote:
On Fri, Aug 11, 2017 at 3:30 PM, Sanne Grinovero
<sanne(a)infinispan.org>
wrote:
> On 11 August 2017 at 14:14, Galder Zamarreño <galder(a)redhat.com> wrote:
> > Hi,
> >
> > Re: https://issues.jboss.org/browse/ISPN-8186
> >
> > I've been looking at TRACE logs and what seems to happen is that is
> that sometimes, when the client needs to create a new Socket, it sends
> using the same localport as the Hot Rod server port. As a result, when the
> client sends something to the server, it also receives it, hence it ends
> finding a request instead of a response. Analysis of the logs linked in the
> JIRA can be found in [1].
> >
> > What I'm not sure about is how to fix this... There are ways to
> potentially pass a specific localport to a Socket [2] but this could be a
> bit messy: It'd require us to generate a random local port and see if that
> works, making sure that's not the server port...
> >
> > However, I think the real problem we're having here is the fact that
> both the server and client are bound to same IP address, 127.0.0.1. A
> simpler solution could be a way to get the server to be in a different IP
> address to the client, but what would that be that IP address and how to
> make sure it always works? Bind the server to eth0?
> >
> > Any other ideas?
>
> You could create multiple aliases for the same loopback device, and
> assign a different IP address to each of them.
>
No need for aliases, we could use directly use any IP from the range
127.0.0.0/8
Just a reminder, the testsuite should be able to run on Linux/Win/MacOS so
I'd stay
away for OS specific extra steps
I tested on a recent Linux and Win, it works, but MacOS requires an alias
to be created...
11:50 a.m.
On 11 Aug 2017, at 16:30, Sanne Grinovero
<sanne(a)infinispan.org> wrote:
On 11 August 2017 at 14:14, Galder Zamarreño <galder(a)redhat.com> wrote:
> Hi,
>
> Re: https://issues.jboss.org/browse/ISPN-8186
>
> I've been looking at TRACE logs and what seems to happen is that is that
sometimes, when the client needs to create a new Socket, it sends using the same localport
as the Hot Rod server port. As a result, when the client sends something to the server, it
also receives it, hence it ends finding a request instead of a response. Analysis of the
logs linked in the JIRA can be found in [1].
>
> What I'm not sure about is how to fix this... There are ways to potentially pass
a specific localport to a Socket [2] but this could be a bit messy: It'd require us to
generate a random local port and see if that works, making sure that's not the server
port...
>
> However, I think the real problem we're having here is the fact that both the
server and client are bound to same IP address, 127.0.0.1. A simpler solution could be a
way to get the server to be in a different IP address to the client, but what would that
be that IP address and how to make sure it always works? Bind the server to eth0?
>
> Any other ideas?
You could create multiple aliases for the same loopback device, and
assign a different IP address to each of them.
But I fail to understand why you don't have specific ports for each
purpose? That's the point for using ports in the first place, no?
^ Hmmm?
The servers in the test use a random port that's available. The clients connect to
these ports. The local ports used by the clients are random. You need to use APIs such as
[2] to fix them.
So, what exactly are you talking about? Are you saying we should fix the local client
ports? As I said in the first post, we could try to find a random port that's not the
server one...
I must admit this scenario sounds very weird... how does Java allow you for a local port
to be bound to a port that's already in use by the server? It doesn't make sense.
I'll be trying to replicate this in a small unit test next few days...
Cheers,
Thanks,
Sanne
>
> Cheers,
>
> [1] https://gist.github.com/galderz/b8549259ff65cb74505c9268eeec96a7
> [2]
http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html#Socket(java...
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Infinispan, Red Hat
1:49 p.m.
On 11 August 2017 at 17:50, Galder Zamarreño <galder(a)redhat.com> wrote:
> On 11 Aug 2017, at 16:30, Sanne Grinovero <sanne(a)infinispan.org> wrote:
>
> On 11 August 2017 at 14:14, Galder Zamarreño <galder(a)redhat.com> wrote:
>> Hi,
>>
>> Re: https://issues.jboss.org/browse/ISPN-8186
>>
>> I've been looking at TRACE logs and what seems to happen is that is that
sometimes, when the client needs to create a new Socket, it sends using the same localport
as the Hot Rod server port. As a result, when the client sends something to the server, it
also receives it, hence it ends finding a request instead of a response. Analysis of the
logs linked in the JIRA can be found in [1].
>>
>> What I'm not sure about is how to fix this... There are ways to potentially
pass a specific localport to a Socket [2] but this could be a bit messy: It'd require
us to generate a random local port and see if that works, making sure that's not the
server port...
>>
>> However, I think the real problem we're having here is the fact that both the
server and client are bound to same IP address, 127.0.0.1. A simpler solution could be a
way to get the server to be in a different IP address to the client, but what would that
be that IP address and how to make sure it always works? Bind the server to eth0?
>>
>> Any other ideas?
>
> You could create multiple aliases for the same loopback device, and
> assign a different IP address to each of them.
>
> But I fail to understand why you don't have specific ports for each
> purpose? That's the point for using ports in the first place, no?
^ Hmmm?
The servers in the test use a random port that's available. The clients connect to
these ports. The local ports used by the clients are random. You need to use APIs such as
[2] to fix them.
So, what exactly are you talking about? Are you saying we should fix the local client
ports? As I said in the first post, we could try to find a random port that's not the
server one...
It should be clear that all sources of randomness are your enemy?
For obvious reasons we have to endure with reproducibility complexity
caused by using threads, timing, network packets interleaving... you
can't do much about these but you could at least try to introduce more
of it.
I would just hard code all ports in the testsuite, and test for their
availability during testsuite initialization. This would have some
other nice consequences, like improving the likelyhood to detect
leaked sockets.
You might remember that the main reason I proposed a "timer service"
years ago was to be able to mock time passage and make that all
reproducible even in the presence of GC and slow machines; eventually
you'd have been able to remove all reasons to actually run tests in
parallel as all needs for idle waiting would be controlled, so further
reducing variability.
My whole point has always been that you need to reduce randomness to
improve the testsuite reliability.
Thanks,
Sanne
I must admit this scenario sounds very weird... how does Java allow you for a local port
to be bound to a port that's already in use by the server? It doesn't make sense.
I'll be trying to replicate this in a small unit test next few days...
Cheers,
>
> Thanks,
> Sanne
>
>
>>
>> Cheers,
>>
>> [1] https://gist.github.com/galderz/b8549259ff65cb74505c9268eeec96a7
>> [2]
http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html#Socket(java...
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Infinispan, Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:56 p.m.
On 08/11/2017 11:50 AM, Galder Zamarreño wrote:
I must admit this scenario sounds very weird... how does Java allow
you for a local port to be bound to a port that's already in use by the server? It
doesn't make sense.
You cannot bind to a port that's already in use.
But if you're trying to connect to a port in the ephemeral range that's
not in use, and the OS happens to assign that same IP:port to the local
socket, it can connect to itself.
(We've run into this in JGroups before, and it was a pain to track down
what was going on).
-Dennis
1:48 a.m.
Right: the localHost:localPort combo of the client socket cannot be the
same as that of the remoteHost:remotePort.
Do you happen to have the link to the JGroups issue? I also remember
this, but googling I failed to find it. Perhaps we can use the same
solution here that we used for the JGRP issue.
I vaguely recall we checked the client's local address:port against some
server address:port and closed/re-created it is the same.
On 11/08/17 20:56, Dennis Reed wrote:
On 08/11/2017 11:50 AM, Galder Zamarreño wrote:
> I must admit this scenario sounds very weird... how does Java allow you for a local
port to be bound to a port that's already in use by the server? It doesn't make
sense.
You cannot bind to a port that's already in use.
But if you're trying to connect to a port in the ephemeral range that's
not in use, and the OS happens to assign that same IP:port to the local
socket, it can connect to itself.
(We've run into this in JGroups before, and it was a pain to track down
what was going on).
-Dennis
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban | http://www.jgroups.org
8:04 a.m.
I did run a local test and indeed you get a bind exception if trying to bind a local port
that's in use as server port:
https://github.com/galderz/java-sandbox/blob/master/src/main/java/j/net/L...
I'll check JGRP source and JIRA and try to dig this further.
Cheers,
On 14 Aug 2017, at 08:48, Bela Ban <belaban(a)mailbox.org>
wrote:
Right: the localHost:localPort combo of the client socket cannot be the
same as that of the remoteHost:remotePort.
Do you happen to have the link to the JGroups issue? I also remember
this, but googling I failed to find it. Perhaps we can use the same
solution here that we used for the JGRP issue.
I vaguely recall we checked the client's local address:port against some
server address:port and closed/re-created it is the same.
On 11/08/17 20:56, Dennis Reed wrote:
> On 08/11/2017 11:50 AM, Galder Zamarreño wrote:
>> I must admit this scenario sounds very weird... how does Java allow you for a
local port to be bound to a port that's already in use by the server? It doesn't
make sense.
>
> You cannot bind to a port that's already in use.
>
> But if you're trying to connect to a port in the ephemeral range that's
> not in use, and the OS happens to assign that same IP:port to the local
> socket, it can connect to itself.
>
> (We've run into this in JGroups before, and it was a pain to track down
> what was going on).
>
> -Dennis
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Bela Ban | http://www.jgroups.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Infinispan, Red Hat
8:39 a.m.
Is this the issue, Bela?
https://issues.jboss.org/browse/JGRP-1116
Thanks,
Alan
----- Original Message -----
From: "Galder Zamarreño" <galder(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Monday, August 14, 2017 9:04:50 AM
Subject: Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186
I did run a local test and indeed you get a bind exception if trying to bind
a local port that's in use as server port:
https://github.com/galderz/java-sandbox/blob/master/src/main/java/j/net/L...
I'll check JGRP source and JIRA and try to dig this further.
Cheers,
> On 14 Aug 2017, at 08:48, Bela Ban <belaban(a)mailbox.org> wrote:
>
> Right: the localHost:localPort combo of the client socket cannot be the
> same as that of the remoteHost:remotePort.
>
> Do you happen to have the link to the JGroups issue? I also remember
> this, but googling I failed to find it. Perhaps we can use the same
> solution here that we used for the JGRP issue.
>
> I vaguely recall we checked the client's local address:port against some
> server address:port and closed/re-created it is the same.
>
> On 11/08/17 20:56, Dennis Reed wrote:
>> On 08/11/2017 11:50 AM, Galder Zamarreño wrote:
>>> I must admit this scenario sounds very weird... how does Java allow you
>>> for a local port to be bound to a port that's already in use by the
>>> server? It doesn't make sense.
>>
>> You cannot bind to a port that's already in use.
>>
>> But if you're trying to connect to a port in the ephemeral range that's
>> not in use, and the OS happens to assign that same IP:port to the local
>> socket, it can connect to itself.
>>
>> (We've run into this in JGroups before, and it was a pain to track down
>> what was going on).
>>
>> -Dennis
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Bela Ban | http://www.jgroups.org
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Infinispan, Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:18 a.m.
Yes, thanks Alan,
so what we did was check the local (ephemeral) port after the bind, and
close/re-open/re-bind if that local port was the same as the destination
port (the server's port).
This should work as fix for this specific issue here, too, unless I'm
mistaken.
On 14/08/17 15:39, Alan Field wrote:
Is this the issue, Bela?
https://issues.jboss.org/browse/JGRP-1116
Thanks,
Alan
----- Original Message -----
> From: "Galder Zamarreño" <galder(a)redhat.com>
> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
> Sent: Monday, August 14, 2017 9:04:50 AM
> Subject: Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186
>
> I did run a local test and indeed you get a bind exception if trying to bind
> a local port that's in use as server port:
>
>
https://github.com/galderz/java-sandbox/blob/master/src/main/java/j/net/L...
>
> I'll check JGRP source and JIRA and try to dig this further.
>
> Cheers,
>
>> On 14 Aug 2017, at 08:48, Bela Ban <belaban(a)mailbox.org> wrote:
>>
>> Right: the localHost:localPort combo of the client socket cannot be the
>> same as that of the remoteHost:remotePort.
>>
>> Do you happen to have the link to the JGroups issue? I also remember
>> this, but googling I failed to find it. Perhaps we can use the same
>> solution here that we used for the JGRP issue.
>>
>> I vaguely recall we checked the client's local address:port against some
>> server address:port and closed/re-created it is the same.
>>
>> On 11/08/17 20:56, Dennis Reed wrote:
>>> On 08/11/2017 11:50 AM, Galder Zamarreño wrote:
>>>> I must admit this scenario sounds very weird... how does Java allow you
>>>> for a local port to be bound to a port that's already in use by the
>>>> server? It doesn't make sense.
>>>
>>> You cannot bind to a port that's already in use.
>>>
>>> But if you're trying to connect to a port in the ephemeral range
that's
>>> not in use, and the OS happens to assign that same IP:port to the local
>>> socket, it can connect to itself.
>>>
>>> (We've run into this in JGroups before, and it was a pain to track down
>>> what was going on).
>>>
>>> -Dennis
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Bela Ban | http://www.jgroups.org
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban | http://www.jgroups.org
10:23 a.m.
On 08/11/2017 08:14 AM, Galder Zamarreño wrote:
I've been looking at TRACE logs and what seems to happen is that
is that sometimes, when the client needs to create a new Socket, it sends using the same
localport as the Hot Rod server port. As a result, when the client sends something to the
server, it also receives it, hence it ends finding a request instead of a response.
What I'm not sure about is how to fix this... There are ways to
potentially pass a specific localport to a Socket [2] but this could be a bit messy:
It'd require us to generate a random local port and see if that works, making sure
that's not the server port...
To fix that don't use an ephemeral port for the server.
However, I think the real problem we're having here is the fact
that both the server and client are bound to same IP address, 127.0.0.1. A simpler
solution could be a way to get the server to be in a different IP address to the client,
but what would that be that IP address and how to make sure it always works? Bind the
server to eth0?
You can't use a different IP for the client and server unless you have
two public IPs that can communicate with each other (not very common),
and explicitly set the client's IP. That would be overkill just to work
around this particular issue.
Also note that it can only happen if the client is connecting to an
unused IP:port. If the server is currently running on the port, it can't.
-Dennis
10:26 a.m.
You could try binding to 127.0.0.2?
On Fri, Aug 11, 2017 at 2:14 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
Hi,
Re: https://issues.jboss.org/browse/ISPN-8186
I've been looking at TRACE logs and what seems to happen is that is that
sometimes, when the client needs to create a new Socket, it sends using the
same localport as the Hot Rod server port. As a result, when the client
sends something to the server, it also receives it, hence it ends finding a
request instead of a response. Analysis of the logs linked in the JIRA can
be found in [1].
What I'm not sure about is how to fix this... There are ways to
potentially pass a specific localport to a Socket [2] but this could be a
bit messy: It'd require us to generate a random local port and see if that
works, making sure that's not the server port...
However, I think the real problem we're having here is the fact that both
the server and client are bound to same IP address, 127.0.0.1. A simpler
solution could be a way to get the server to be in a different IP address
to the client, but what would that be that IP address and how to make sure
it always works? Bind the server to eth0?
Any other ideas?
Cheers,
[1] https://gist.github.com/galderz/b8549259ff65cb74505c9268eeec96a7
[2] http://docs.oracle.com/javase/6/docs/api/java/net/Socket.
html#Socket(java.net.InetAddress,%20int,%20java.net.InetAddress,%20int)
<http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html#Socket%28ja...
--
Galder Zamarreño
Infinispan, Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:17 a.m.
On 08/11/2017 03:14 PM, Galder Zamarreño wrote:
Hi,
Re: https://issues.jboss.org/browse/ISPN-8186
I've been looking at TRACE logs and what seems to happen is that is that sometimes,
when the client needs to create a new Socket, it sends using the same localport as the Hot
Rod server port. As a result, when the client sends something to the server, it also
receives it, hence it ends finding a request instead of a response. Analysis of the logs
linked in the JIRA can be found in [1].
I've always assumed that a TCP connection is a two-end pipe, both being
successfully connected to the remote side and looping back messages to
the client sounds strange... have you googled if this is a bug or
feature? Or is the client talking to itself only despite the server
being successfully bound to listen on the port?
What I'm not sure about is how to fix this... There are ways to potentially pass a
specific localport to a Socket [2] but this could be a bit messy: It'd require us to
generate a random local port and see if that works, making sure that's not the server
port...
Clients use ephemeral ports that have limited range (32k+ on Linux?),
what about making sure that the server port is out of this range?
However, I think the real problem we're having here is the fact
that both the server and client are bound to same IP address, 127.0.0.1. A simpler
solution could be a way to get the server to be in a different IP address to the client,
but what would that be that IP address and how to make sure it always works? Bind the
server to eth0?
I don't think that having both on the same IP is a real problem.
Testsuite should not listen on externally accessible ports, besides the
fact that the computer may not have any ports (ok, that's rather
theoretical nowadays) there's a security risk involved. And if the
machine has firewall set to block connection to externally accessible
ports (even from local addresses), the testsuite would fail.
Radim
Any other ideas?
Cheers,
[1] https://gist.github.com/galderz/b8549259ff65cb74505c9268eeec96a7
[2]
http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html#Socket(java...
--
Galder Zamarreño
Infinispan, Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
2973
days inactive
2976
days old
infinispan-dev@lists.jboss.org
14 comments
8 participants
participants (8)
-
Alan Field -
Bela Ban -
Dennis Reed -
Galder Zamarreño -
Gustavo Fernandes -
Radim Vansa -
Sanne Grinovero -
Vojtech Juranek