socket pool and keeping session id

lionel.duboeuf · 2014-07-03T17:01:36+00:00

Hello! On Mon, Jul 14, 2014 at 5:40 AM, Stefan Parvu wrote: > The very first signs of DTrace on FreeBSD are since 2005 or 2006, if Im not > wrong. &gt...

socket pool and keeping session id

lionel.duboeuf

hi all,

I have a project where my server communicate with a tcp-ip socket
I'm using co-socket api thanks to resty.mysql resty.redis great examples.
Server side implemenation works with sessions, so that if i want to communicate with server i have to obtain a session. Note that session stick with the tcp-id socket.
Now for the next http requests , i would like to be able to reuse a socket from the pool and use the apropriate session_id stored somewhere in the code.
i don't know how i can handle that.

Thanks a lot.

Lionel

agentzh

Hello!

On Thu, Jul 3, 2014 at 2:01 AM, Lionel Duboeuf wrote:
> I have a project where my server communicate with a tcp-ip socket
> I'm using co-socket api thanks to resty.mysql resty.redis great examples.
> Server side implemenation works with sessions, so that if i want to
> communicate with server i have to obtain a session. Note that session stick
> with the tcp-id socket.
> Now for the next http requests , i would like to be able to reuse a socket
> from the pool and use the apropriate session_id stored somewhere in the
> code.

Well, you can just use the session ID to construct your own connection
pool name (the default pool name is "<host>:<port>" or
"<unix-socket-path" if not specified). To do that, just specify the
"pool" option for the connect() method.

Please check out the official documentation for the cosocket connect()
method for more details on the optional "pool" option:
https://github.com/openresty/lua-nginx-module#tcpsockconnect

Best regards,
-agentzh

agentzh

Hello!

On Thu, Jul 3, 2014 at 4:49 PM, Yichun Zhang (agentzh) wrote:
>
> Well, you can just use the session ID to construct your own connection
> pool name (the default pool name is "<host>:<port>" or
> "<unix-socket-path" if not specified). To do that, just specify the
> "pool" option for the connect() method.
>

But note that connection pools are always per worker process and you
cannot control which worker process handles which request. This is
merely a connection reuse and be prepared for a "miss" in the
connection pool. Also be careful when you can have a lot of different
sessions (like tens of thousands or even more) and you may end of with
too many connection pools that have a poor hit rate overall).

-agentzh

lionel.duboeuf

hi,
Thanks for your quick response.

the problem here is session_id is only known after sock:connect() So i can't associate sessionid with pool at connect time.

Le vendredi 4 juillet 2014 01:55:03 UTC+2, agentzh a écrit :

Hello!

On Thu, Jul 3, 2014 at 4:49 PM, Yichun Zhang (agentzh) wrote:
>
> Well, you can just use the session ID to construct your own connection
> pool name (the default pool name is "<host>:<port>" or
> "<unix-socket-path" if not specified). To do that, just specify the
> "pool" option for the connect() method.
>

But note that connection pools are always per worker process and you
cannot control which worker process handles which request. This is
merely a connection reuse and be prepared for a "miss" in the
connection pool. Also be careful when you can have a lot of different
sessions (like tens of thousands or even more) and you may end of with
too many connection pools that have a poor hit rate overall).

-agentzh

agentzh

Hello!

On Fri, Jul 4, 2014 at 7:53 AM, Lionel Duboeuf wrote:
>
> the problem here is session_id is only known after sock:connect()  So i
> can't associate sessionid with pool at connect time.
>

Then I don't think I understand your requirements in the first place :)

Maybe you should elaborate your use case with a code example or something?

Regards,
-agentzh

lionel.duboeuf

Hello,

Okay, last news, server side session management will change in the future so that session will not be correlated to socket tcp/ip anymore.
This will simplify my problem

Thanks for your help.
regards
Lionel

Le vendredi 4 juillet 2014 20:51:02 UTC+2, agentzh a écrit :

Hello!

On Fri, Jul 4, 2014 at 7:53 AM, Lionel Duboeuf wrote:
>
> the problem here is session_id is only known after sock:connect() So i
> can't associate sessionid with pool at connect time.
>

Then I don't think I understand your requirements in the first place :)

Maybe you should elaborate your use case with a code example or something?

Regards,
-agentzh