On 11 August 2017 at 17:50, Galder Zamarreño <gal...@redhat.com> wrote: > > >> On 11 Aug 2017, at 16:30, Sanne Grinovero <sa...@infinispan.org> wrote: >> >> On 11 August 2017 at 14:14, Galder Zamarreño <gal...@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.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
