[
https://issues.apache.org/jira/browse/AXIS2-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467047
]
Josef Stadelmann commented on AXIS2-1991:
-----------------------------------------
Hi Deepal,
I think you do not understand my problem. Maybe I made things not clear
enougth, So here is my problem described again.
My client#1 is continously sending messages out of a for{ } loop, as fast as
possible.
My Client#1 never times out and reaches the end of the for{ } loop after 500 or
50000 iterations.
(I am glad to send you the code but did it already by e-mails)
The problem again:
While client#1 sends continously messages, I launch client#2.
It then takes only seconds until client#1 runs into the exception as reported
by the JIRA AXIS2-1991.
To analyse the problem myself: I went deep into axis2 core code starting at the
HttpSeervlet and the Axis2Servlet where multiple threads arrive and continue. I
used a debugger to trace where the diffeerent calls went through.
My understanding is that per thread one large object modell is instantiated. AND
Each object in the model runs in the same thread. AND
Objects in the modell interoperate with each on another in the same thread.
BUT - Each session operates on such an object modell AND each session runs in
it's owne thread - hence we have N sessions running in N threads leading to the
creation of N object-modell-instances.
Please correct me if I am wrong as this is essential for my understanding!
If the creation of ServiceGroupContextID IS threadsafe, which I don't beleave
it is, - up to and including the CREATION of a ServiceGroupContextID, then we
would obviously not have the reported problem and effects on client#1. Unless
the storage of the ServiceGroupContextID is not threadsafe.
I assume we should have one ServiceGroupContextID per session/thread AND not
beeing shared among sessions/threads? ? Is this right or wrong?
If ONE ServiceGroupContextID is created per thread and remains threadsafe then
all would be fine and client #2 would not disturb anything in the vicinity of
clinet#1. Otherwhise if a ServiceGroupContextID spanes over multiple threads,
then client#1 is in trouble short after a launch of client#2.
If the creation of a ServiceGrouopContextID is not thread safe, and if a new
client does not know anything about an existing ServiceGroupContextID because
Axis2 does not return an EXISTING IN-USE ServiceGroupContextID to client#2 on
its first call, but creates a new ServiceGroupContextID, then it is obvious
what happens to client#1 on its next call. EXCEPTION as reported by this JIRA
I have NOT found in axis2 code where a TEST is made for an existing valid
IN-USE ServiceGroupContextID, before a new ServiceGroupContextID is created.
Is this true or wrong?
Toward that, the test should aim at NOT OVERRIDING an existing USED
ServiceGroupContextID.
Up today, any initial call of a client#2 re-creates and overrides the existing
ServiceGroupContextID in scope=soapsession, which leads to a call of
MyService.destroy() followed by a call to MyService.init() as seen and reported.
If a ServiceGroupContextID is shared between sessions, and among threads, then
axis2 core code has to TEST for an EXISTING IN-USE ServiceGroupContextID and
return this EXISTING ServiceGroupContextID to any new client#n calling. This
would then not hamper client#1 (all previously launched clients) coming in with
the previous old ServiceGroupContextID.
If mulitiple threads from multiple client sessions come into axis2 AND all IS
threadsafe, then each client-session can create its very own
ServiceGroupContextID and this creation of a ServiceGroupContextID enforced by
client#2 and more will not make client#1 fail, which is the case today in
scope=soapsession. I have not a time-out-problem, as all my clients run
succesfully.
How is session defined in relation to thread?
Client#1 in session#1 in thread#1 creates/stores the ServiceGroupContextID#1 in
thread#common location and then uses ServiceGroupContextID#1
Client#2 in session#2 in thread#2 creates/stores the ServiceGroupContextID#2 in
thread#common location and then uses ServiceGroupContextID#2
It has overriden in thread#common location ServiceGroupContextID#1 with #2
Client#1 in session#1 in thread#1 comes in to axis2 with
ServiceGroupContextID#1 which is compared to the value stored in thread#common,
which is ServiceGroupContextID#2, not as expected, and this leades to an
exception and this makes client#1 fail.
And so on with each new client#number.
The problem can be cured by
a) a threadsafe storage location for the ServiceGroupContextID OR
b) by a check for a IN-USE ServiceGroupContextID followed by a return of an
IN-USE old ServiceGroupContextID if ServiceGroupContextID's can be shared among
sessions and threads. If not this is not the solution.
In case the ServiceGroupContextID is used to select the proper/correct
ServiceGroupContext for a given thread/session calling in to axis2, then
threadsafety of the storage location for ServiceGroupContextID needs
reevaluation for scope=soapsession.
Regards and thanks a lot for looking at it.
Josef
> ServiceGroupContextID re-created by second client calling in
> scope=soapsession making first client session fail with exception unknown
> ServiceGroupContextID
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-1991
> URL: https://issues.apache.org/jira/browse/AXIS2-1991
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.1
> Environment: Windows 2000, tomcat, axis2-1.1,
> Reporter: Josef Stadelmann
>
> Hi session-managers,
> I'm running my client and server with modules addressing-1.1, logging,
> soapmonitor-1.1 engaged and have set scope=soapsession
> MyService.java got the additional methods
>
> public void init(ServiceContext sCtx) {
> this.sc = sCtx;
> this.log.info(sc.toString()+" init() called ");
> }
>
> public void destroy(ServiceContext sCtx) {
> if(!this.sc.toString().equals(sCtx.toString())){
> this.log.error("ServiceContext on init() and destroy() not equal
> in ");
> }
> this.log.info(sc.toString()+" destroy() called ");
> }
> public void setOperationContext(OperationContext oCtx) {
> this.oc = oCtx;
> this.log.info(oc.toString()+" setOperationContext() called ");
> }
>
> I start client #1 which has the effect that MyService.init() is called; so
> far so right!
> Client #1 then loops and sends continously messages to MyService.echo()
> I start client #2 which has the effect that MyService.destroy() is called
> followed by MyService.init()
> This has the effect that client #1 fails with an "invalid group context id
> exception"
> Josef
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
