axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danus...@wso2.com>
Subject Re: Implementing Http Keep Alive and Transport level session support for Axis2/C
Date Mon, 21 Dec 2009 05:13:43 GMT
Hi Damitha,

A couple of questions ...


> A service could support session by creating a hash table filling it with
> key value pairs and setting it to the message context.
>

Since this is done at the service level - a higher level - I thinks its
nicer to have a simple API call to set session data rather than having to
create a new hash table and set that in the message context. (e.g.
msg_ctx_set_session_data(key, value) or something like that)


> Then it add the Set-Cookie header into the response message which has the
> cookie header value of session id and expiration time.
>

Is the expiration time configurable?


> In the client side the sessions are stored in a session map against the
> server.
>

What do you mean by storing sessions against the server?

Are there any plans to make the session data persistent so that we can have
persistent sessions?.


> Http Keep Alive support for Axis2/C client side.


 Do we support Keep Alive on the server side?. IIRC the HTTP transport
receiver closes the connection on the server side?.

>From there onwards it will reuse this http client for sending the messages.


The main issue in reusing an HTTP client and hence the persisted connection
is that in case the server goes down and maybe comes up again, the persisted
connections that we have are no longer valid. If you now try to reuse these
connections, the behavior is undefined. Therefore you have to do a socket
select to check the validity of a persisted connection prior to reusing it.
How do you handle this situation in your implementation?.

Danushka

-- 
Danushka Menikkumbura
Technical Lead, WSO2 Inc.

blog : http://danushka-menikkumbura.blogspot.com/

http://wso2.com/ - "The Open Source SOA Company"

Mime
View raw message