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