destroy(SvcCtx) is never invoked when service deployed in request session scope
-------------------------------------------------------------------------------

                 Key: AXIS2-3387
                 URL: https://issues.apache.org/jira/browse/AXIS2-3387
             Project: Axis 2.0 (Axis2)
          Issue Type: Bug
          Components: kernel
    Affects Versions: 1.2, 1.3
            Reporter: Mario A. Rodriguez


My service implementation class contains the following method signatures:

        public void init(ServiceContext context)
        {
                System.out.println("init called");
        }

        public void destroy(ServiceContext context)
        {
                System.out.println("destroy called");
        }

The service is then deployed using the default "request" scope.

When I invoke the service the init() method is always invoked, but the 
destroy() method is never called. If I understand the doc correctly the 
destroy() method should be invoked after the operation completes, or perhaps 
I'm mistaken?

If I change the session scope to "soapsession" then the destroy() method is 
actually invoked. Although it doesn't appear to be invoked automatically after 
the 30 second timeout, it waits until another request arrives and then clears 
out any sessions older than 30 seconds.

My service implementation acquires a number of resources in the init() method 
and I was hoping to rely on the calls to destroy() in order to free those 
resources, preferably after completion of every request. The next best option 
would have been to use a short timeout for the SOAP session, but it looks like 
neither session scope is able to provide a deterministic way to free resources.

Any suggestions would be appreciated.

Thanks.

-- 
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]

Reply via email to