Hi Andreas, Unfortunately, the proxy sample app has not been tested under heavy load. It’s just an example test app.
If you have a patch, please do push it to avoid the issue in the future. Otherwise, I’ll take a look at it. Regards, Florin > On May 29, 2020, at 6:29 AM, Andreas Schultz <andreas.schu...@travelping.com> > wrote: > > Hi, > > Tracked it down. It's not the session logic, but the connection handling in > the proxy sample hs_app. > > The proxy is calling vnet_disconnect_session on both sessions in > delete_proxy_session. That function is invoked from the disconnect and reset > callback. Turns out that calling vnet_disconnect_session on the session the > callback was invoked for, messes up the session state. > > Andreas > > Am Fr., 29. Mai 2020 um 14:32 Uhr schrieb Andreas Schultz > <andreas.schu...@travelping.com <mailto:andreas.schu...@travelping.com>>: > Hi, > > It seems that the {v4,v6}_session_hash is leaking entries. When creating > large amounts of TCP session (incoming and outgoing) we are observing entries > in the session_hash pointing to already deleted sessions. > > I have verified with a somewhat hackish check in session_delete that > sometimes a session is deleted that still has an active entry in the session > hash. The entry does not get deleted later. Under the right circumstances, > that invalid entry is then picked up by session_lookup_connection_wt4, > leading to crash. > > So far the cause seems to be the session_delete in > session_transport_delete_notify when the status is STATE_CLOSED. I have no > idea how the session ends up there. > > Regards, > Andreas > > -- > Andreas Schultz > > > > -- > Andreas Schultz >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16574): https://lists.fd.io/g/vpp-dev/message/16574 Mute This Topic: https://lists.fd.io/mt/74542352/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
