Danushka Menikkumbura wrote:
> 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)
This is good improvement. However my initial thought was to avoid api
changes as much as possible.
>
>
> 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?
You can change AXIS2_TRANSPORT_SESSION_EXPIRE_DURATION in header file
which is defaulted to 60 seconds. However deployment time configuration
is not possible yet.
>
>
> 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?
cookies are stored in a hash table with key as server:port and value as
the cookie value.
>
> Are there any plans to make the session data persistent so that we can
> have persistent sessions?.
Sessions are made persistent at server side by storing them using dbd
apache module. No plan yet to make them persistent at client side.
>
>
> Http Keep Alive support for Axis2/C client side.
>
>
> Do we support Keep Alive on the server side?.
This support is provided by Apache. However it is not yet implementd for
stand alone Axis2/C server. It just send back connection close header in
HTTP1.1 case and no connection headre in HTTP1.0 case.
> 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?.
Are you talking about tcp keep alive support?. Adding that to Axis2/C is
a good option.
Thanks,
Damitha
>
> Danushka
>
> --
> Danushka Menikkumbura
> Technical Lead, WSO2 Inc.
>
> blog : http://danushka-menikkumbura.blogspot.com/
>
> http://wso2.com/ - "The Open Source SOA Company"
>
>
--
__________________________________________________________________
Damitha Kumarage
Technical Lead; WSO2 Inc.
"Oxygenating the Web Service Platform; " http://www.wso2.com/
blog: " http://damithakumarage.wordpress.com/
__________________________________________________________________
|