Hi Rushi, If the application crashes/restarts without detaching, it will take some time for vpp to detect that. In particular, the binary api needs to first detect that the binary api client went away (about 30s) and then everything should be cleaned up.
To solve that, you could try updating to vpp master and instead of using the binary api for attachment, switch to the new dedicated socket api, i.e., add use-app-socket-api to the session stanza in vpp’s startup.conf and "app-socket-api /var/run/vpp/app_ns_sockets/default” to vcl.conf. The new api detects when vcl’s end of the socket goes down and it detaches the app. Regards, Florin > On Nov 23, 2020, at 2:59 PM, Rush iii <rushik1...@gmail.com> wrote: > > Hi, > > Having an issue with VPP v20.05.1 running on Centos 8.2 1u server. > My application opens a couple of VCL sessions to receive packets from the > interface - > One of the application threads (input thread) calls the following api to > establish new session- > vppcom_worker_register() > vppcom_epoll_create() > vppcom_session_create(VPPCOM_PROTO_UDP, 0) > vppcom_session_attr(sock, VPPCOM_ATTR_SET_CONNECTED, NULL, NULL) > > rv_vpp = vppcom_session_bind (sock, &endpt); > rv_vpp = vppcom_session_listen (sock, 10); > rv_vpp = vppcom_epoll_ctl (epfd, EPOLL_CTL_ADD, sock, &listen_ev); > ---- > Most of the time it works fine. However, sometimes, when the application is > restarted, new sessions are created, but the old ones don't clear up. > And packets received keep getting added to those older sessions, but since > the application is already restarted and created new sessions, the received > packets don't make it to the application. Sometimes it takes a really long > time for the stale sessions to clear up. > > When I tried to manually clear those old/stale sessions from vppctl, it > executed the 'clear session' without any errors but doesn't really clear the > session. > > [root@J3SGISNCIGW03 download]# vppctl > _______ _ _ _____ ___ > __/ __/ _ \ (_)__ | | / / _ \/ _ \ > _/ _// // / / / _ \ | |/ / ___/ ___/ > /_/ /____(_)_/\___/ |___/_/ /_/ > > vpp# sh threads > ID Name Type LWP Sched Policy (Priority) lcore > Core Socket State > 0 vpp_main 2441327 other (0) 1 > 1 0 > 1 vpp_wk_0 workers 2441329 other (0) 2 > 2 0 > 2 vpp_wk_1 workers 2441330 other (0) 3 > 3 0 > 3 vpp_wk_2 workers 2441331 other (0) 4 > 4 0 > 4 vpp_wk_3 workers 2441332 other (0) 5 > 8 0 > > vpp# sh session thread 3 verbose > [3:0][U] 2001:5b0:ffff:501:b883:31f:49e:78c0:7429-OPENED 301830 0 > [3:1][U] 2001:5b0:ffff:501:b883:31f:49e:78c0:7429-OPENED 114268 0 > Thread 3: 2 sessions matched filter > > vpp# clear session thread 3 session 0 > vpp# sh session thread 3 verbose > [3:0][U] 2001:5b0:ffff:501:b883:31f:49e:78c0:7429-OPENED 304282 0 > [3:1][U] 2001:5b0:ffff:501:b883:31f:49e:78c0:7429-OPENED 114644 0 > Thread 3: 2 sessions matched filter > vpp# > > Could anyone suggest if something else can be done to debug this through > vppctl other than possibly loading a debug build with traces enabled? > Thank you for your help. > > Regards, > Rushi > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18125): https://lists.fd.io/g/vpp-dev/message/18125 Mute This Topic: https://lists.fd.io/mt/78465935/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
