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/
__________________________________________________________________
