Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Bela Ban]

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" 
>> To: "infinispan -Dev List" 
>> 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/LocalPortClash.java
>>
>> I'll check JGRP source and JIRA and try to dig this further.
>>
>> Cheers,
>>
>>> On 14 Aug 2017, at 08:48, Bela Ban  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@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> --
>>> Bela Ban | http://www.jgroups.org
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

-- 
Bela Ban | http://www.jgroups.org

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Alan Field]

Is this the issue, Bela?

https://issues.jboss.org/browse/JGRP-1116

Thanks,
Alan

- Original Message -
> From: "Galder Zamarreño" 
> To: "infinispan -Dev List" 
> 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/LocalPortClash.java
> 
> I'll check JGRP source and JIRA and try to dig this further.
> 
> Cheers,
> 
> > On 14 Aug 2017, at 08:48, Bela Ban  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@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> 
> > 
> > --
> > Bela Ban | http://www.jgroups.org
> > 
> > ___
> > infinispan-dev mailing list
> > infinispan-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Galder Zamarreño
> Infinispan, Red Hat
> 
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Galder Zamarreño]

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/LocalPortClash.java

I'll check JGRP source and JIRA and try to dig this further.

Cheers,

> On 14 Aug 2017, at 08:48, Bela Ban  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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> -- 
> Bela Ban | http://www.jgroups.org
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Infinispan, Red Hat


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Vojtech Juranek]

> Any other ideas?

I'd put some limits on random server port. If server port is under 32k, it 
should work on most of platforms I guess. But I'd agree with Sanne here and 
reconsider, if we should use random ports at all.

signature.asc
Description: This is a digitally signed message part.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Bela Ban]

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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

-- 
Bela Ban | http://www.jgroups.org

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Dennis Reed]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Sanne Grinovero]

On 11 August 2017 at 17:50, Galder Zamarreño  wrote:
>
>
>> On 11 Aug 2017, at 16:30, Sanne Grinovero  wrote:
>>
>> On 11 August 2017 at 14:14, 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].
>>>
>>> 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.net.InetAddress,%20int,%20java.net.InetAddress,%20int)
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Gustavo Fernandes]

On Fri, Aug 11, 2017 at 5:48 PM, Gustavo Fernandes 
wrote:

> On Fri, Aug 11, 2017 at 3:30 PM, Sanne Grinovero 
> wrote:
>
>> On 11 August 2017 at 14:14, 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].
>> >
>> > 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...
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Gustavo Fernandes]

On Fri, Aug 11, 2017 at 3:30 PM, Sanne Grinovero 
wrote:

> On 11 August 2017 at 14:14, 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].
> >
> > 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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Galder Zamarreño]

> On 11 Aug 2017, at 16:30, Sanne Grinovero  wrote:
> 
> On 11 August 2017 at 14:14, 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].
>> 
>> 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.net.InetAddress,%20int,%20java.net.InetAddress,%20int)
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>> 
>> 
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Infinispan, Red Hat


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Radim Vansa]

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.net.InetAddress,%20int,%20java.net.InetAddress,%20int)
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa 
JBoss Performance Team

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Gustavo Fernandes]

You could try binding to 127.0.0.2?


On Fri, Aug 11, 2017 at 2: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].
>
> 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)
> 
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Dennis Reed]

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
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Sanne Grinovero]

On 11 August 2017 at 14:14, 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].
>
> 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.net.InetAddress,%20int,%20java.net.InetAddress,%20int)
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

[Galder Zamarreño]

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)
--
Galder Zamarreño
Infinispan, Red Hat


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev