Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Address already in use: Race condition between isolated executions
Sorry for the very late reply and thank you for working on it

I built it from the source and tested it with the simple example above


I was expecting it to leave an exception telling that the address was already in use, instead of hanging the process.

The behavior now is that the second connection is successful even though the same port was used.

When inspecting the system tcp ports with 'netstat -atn', it seems that both are created with a 'double-mapping' (port 50000)

(base) marcelo@Lenovo-Legion-5-15IMH05H:~$ netstat -atn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:34463           0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN    
tcp        0      0 127.0.0.1:50000         127.0.0.1:45794         ESTABLISHED
tcp        0      0 192.168.1.5:48216       216.58.202.142:443      ESTABLISHED
tcp        0      0 192.168.1.5:55908       3.85.152.15:443         ESTABLISHED
tcp        0      0 127.0.0.1:60188         127.0.0.1:59996         TIME_WAIT  
tcp        0      0 127.0.0.1:45794         127.0.0.1:50000         ESTABLISHED
tcp        0      0 127.0.0.1:60192         127.0.0.1:59996         TIME_WAIT  
tcp        0      0 192.168.1.5:45396       75.2.53.94:443          ESTABLISHED
tcp        0      0 192.168.1.5:33528       198.252.206.25:443      ESTABLISHED
tcp        0      0 127.0.0.1:43994         127.0.0.1:34859         TIME_WAIT  
tcp        0      0 127.0.0.1:50000         127.0.0.1:45798         ESTABLISHED
tcp        0      0 192.168.1.5:48220       216.58.202.142:443      TIME_WAIT  
tcp        0      0 192.168.1.5:58644       3.225.183.105:443       ESTABLISHED
tcp        0      0 192.168.1.5:48502       216.58.202.142:443      ESTABLISHED
tcp        0      0 127.0.0.1:56510         127.0.0.1:34165         ESTABLISHED
tcp        0      0 192.168.1.5:43464       52.11.85.228:443        ESTABLISHED
tcp        0      0 192.168.1.5:44560       172.217.28.74:443       ESTABLISHED
tcp        0      0 192.168.1.5:36802       172.217.28.3:443        ESTABLISHED
tcp        0      0 127.0.0.1:45798         127.0.0.1:50000         ESTABLISHED
tcp        0      0 127.0.0.1:34118         127.0.0.1:40919         CLOSE_WAIT
tcp        0      0 192.168.1.5:51196       107.21.203.251:443      ESTABLISHED
tcp        0      0 192.168.1.5:36070       172.217.192.189:443     ESTABLISHED
tcp        0      0 192.168.1.5:36662       34.235.68.102:443       TIME_WAIT  
tcp        0      0 192.168.1.5:37930       172.217.29.229:443      ESTABLISHED
tcp6       0      0 127.0.0.1:6942          :::*                    LISTEN    
tcp6       0      0 127.0.0.1:63342         :::*                    LISTEN    
tcp6       0      0 :::80                   :::*                    LISTEN    
tcp6       0      0 :::34165                :::*                    LISTEN    
tcp6       0      0 :::40919                :::*                    LISTEN    
tcp6       0      0 ::1:631                 :::*                    LISTEN    
tcp6       0      0 127.0.0.1:40919         127.0.0.1:34118         FIN_WAIT2  
tcp6       0      0 127.0.0.1:34165         127.0.0.1:56510         ESTABLISHED


Is this the intended behavior?


Thank you once again


Sincerely,

Marcelo d'Almeida

On Tue, Nov 3, 2020 at 6:10 PM Michael Behrisch <oss@xxxxxxxxxxx> wrote:
Hi,
you are right, this behavior is not useful. I opened a ticket here:
https://github.com/eclipse/sumo/issues/7750. It already has a
preliminary fix but this needs a little more testing. If you like, you
can try the nightly build (showing up tomorrow) or build yourself and
report your findings.

Best regards,
Michael

Am 03.11.20 um 18:08 schrieb Marcelo Andrade Rodrigues D Almeida:
> Hi everyone
>
> Trying to open two simulations with the same port hangs the entire
> execution, instead of raising an exception
>
> Error
> "Error: tcpip::Socket::accept() Unable to create listening socket:
> Address already in use
> Quitting (on error)."
>
>
> I'm currently running several experiments, simultaneously, in isolated
> docker containers. And inside every experiment, running several parallel
> simulations
>
> The problem is that my experiments can step (and eventually does) into
> address conflict problems (race condition) and the hanging prevents any
> chance of retrying it with a new port, suspending the entire experiment
> forever.
>
> The use of synchronization locks prevents address conflicts inside one
> experiment, so I'm basically limited to run one experiment at a time,
> which is very time consuming.
>
>
> As a workaround, I'm going to specify port ranges for each simulation
> and check it for availability
>
> Let me know if there is a better solution as workaround
>
> And thank you in advance
>
>
> P.S. I've included a trivial example to show the hanging behavior, but
> there is nothing special about it.
>
>
> Sincerely,
>
> Marcelo d'Almeida
>
> _______________________________________________
> sumo-user mailing list
> sumo-user@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
>


_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Back to the top