Possible concurrent issue

[bodji]

I have a problem with the library.
I think I know where it could come from.

The library is built with this schema :
1 - Lock conn
2 - Send command/event to socket
3 - Unlock conn
4 - Read channel apiChan/cmdChan to get response

With heavy load of commands, you can see that you can read from channel another response of another comand, since the unlock is before the reading part.

What do you think?

[danbogos]

Hi Mathieu, Unfortunately FreeSWITCH does not provide any mechanism to match requests and replies (there are no "dialog" identifiers), so we need to take the answer and match it with the request in fifo order. On high load I have the feeling that it is FreeSWITCH who reverses the order of replies/drop some (cannot prove it though). What you can do do avoid this high load concurrency is to use the FSockPoolwhere each request is served in a separate connection to FreeSWITCH, hence being impossible to mix requests and replies. You can find here a sample usage of FSockPool: Instantiate: https://github.com/cgrates/cgrates/blob/master/sessionmanager/fssessionmanager.go#L245 Pop/Push: https://github.com/cgrates/cgrates/blob/master/sessionmanager/fssessionmanager.go#L358 Hope this helps. DanB

[bodji]

Thanks !
I'll try with a pool ;)

[bodji]

It's working better with a pool :)

Thanks !