Hi Tahir, If a vcl app/worker is not closed cleanly, it won’t detach from vpp. In vpp 20.05, the binary api infra will detect that vcl's binary api client crashed, and cleanup the stale app state, but only after about 30s. In 21.01 (master latest) after this [1] vcl can be configured to use the session layer’s app socket api. With this, the session layer in vpp detects socket close events (e.g., app crashes) and cleans up stale app state.
More comments inline. [1] https://gerrit.fd.io/r/c/vpp/+/28717 > On Sep 30, 2020, at 12:06 PM, [email protected] wrote: > > we are using vcl library to send/receive, if the application aborts or kill > signal is sent to the application, vcl sessions are still in listening mode > even after the thread containing the vcl sessions is closed. > > we have a process monitor which monitors our application running/not and > immediately reloads the application > > while booting up consecutive time, because the previous session same(IP+port) > will not be closed while trying to open up new session again > I am getting error as connection refused > > below is the list of calls made > vppcom_app_create - in main thread > In receiver thread This is probably an issue. VCL workers are not thread safe and their data structures should only be accessed by threads that have __vcl_worker_index (TLS variable) set to the index of the worker. If this can’t be ensured, consider using VLS (vcl_locked). Otherwise, if two threads compete for a single worker’s message queue (blocking calls/epoll) could result in undefined behavior. > vppcom_worker_register -> vppcom_session_create -> > vppcom_session_attr(VPPCOM_ATTR_SET_CONNECTED) -> vppcom_session_bind -> > vppcom_session_listen > > while exiting thread calling vppcom_session_close -> vppcom_worker_unregister Note that sharing of vcl sessions between workers is also not supported (again, vls may solve this). vppcom_worker_unregister should cleanup associated listener state in vpp as long as the worker is the owner of the listener. That is, if the listener was registered by one vcl worker but a different worker is later unregistered, it will have no effect on the listener state in vpp. Regards, Florin > > getting error while calling vppcom_session_listen > vnet[12346]: session_mq_listen_handler:66: listen returned: -16 > general protection fault ip:7f351eb202d8 sp:7f33b9ffae20 error:0 in > libvppcom.so.20.05[7f351eb03000+2f000] > general protection fault ip:7f351eb202d8 sp:7f33b97f9e20 error:0 > session listen failed errno=-111 > > Kindly let me know if there's some other configuration that I could use. > > vcl.conf > vcl { > rx-fifo-size 4000000 > tx-fifo-size 4000000 > app-scope-local > app-scope-global > api-socket-name /tmp/vpp-api.sock > app-timeout 2 > session-timeout 2 > } > > regards > Tahir > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17623): https://lists.fd.io/g/vpp-dev/message/17623 Mute This Topic: https://lists.fd.io/mt/77224682/21656 Mute #vpp-hoststack:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-hoststack Mute #vppcom:https://lists.fd.io/g/vpp-dev/mutehashtag/vppcom Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
