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

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sanne Grinovero-3
On 11 August 2017 at 14:14, Galder Zamarreño <[hidden email]> 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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dennis Reed
In reply to this post by Galder Zamarreño
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gustavo Fernandes-2
In reply to this post by Galder Zamarreño
You could try binding to 127.0.0.2?


On Fri, Aug 11, 2017 at 2:14 PM, Galder Zamarreño <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Radim Vansa
In reply to this post by Galder Zamarreño
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gustavo Fernandes-2
In reply to this post by Sanne Grinovero-3
On Fri, Aug 11, 2017 at 3:30 PM, Sanne Grinovero <[hidden email]> wrote:
On 11 August 2017 at 14:14, Galder Zamarreño <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Galder Zamarreño
In reply to this post by Sanne Grinovero-3


> On 11 Aug 2017, at 16:30, Sanne Grinovero <[hidden email]> wrote:
>
> On 11 August 2017 at 14:14, Galder Zamarreño <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gustavo Fernandes-2
In reply to this post by Gustavo Fernandes-2


On Fri, Aug 11, 2017 at 5:48 PM, Gustavo Fernandes <[hidden email]> wrote:
On Fri, Aug 11, 2017 at 3:30 PM, Sanne Grinovero <[hidden email]> wrote:
On 11 August 2017 at 14:14, Galder Zamarreño <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sanne Grinovero-3
In reply to this post by Galder Zamarreño
On 11 August 2017 at 17:50, Galder Zamarreño <[hidden email]> wrote:

>
>
>> On 11 Aug 2017, at 16:30, Sanne Grinovero <[hidden email]> wrote:
>>
>> On 11 August 2017 at 14:14, Galder Zamarreño <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dennis Reed
In reply to this post by Galder Zamarreño
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bela Ban-2
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

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

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Vojtech Juranek
In reply to this post by Galder Zamarreño
> 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.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Galder Zamarreño
In reply to this post by Bela Ban-2
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Bela Ban | http://www.jgroups.org
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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" <[hidden email]>
> To: "infinispan -Dev List" <[hidden email]>
> 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 <[hidden email]> 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
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >
> > --
> > Bela Ban | http://www.jgroups.org
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bela Ban-2
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" <[hidden email]>
>> To: "infinispan -Dev List" <[hidden email]>
>> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> --
>>> Bela Ban | http://www.jgroups.org
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

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

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...