axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (AXISCPP-189) Stub falls over after first stub has been deleted
Date Thu, 07 Oct 2004 03:50:51 GMT
The following comment has been added to this issue:

     Author: Samisa Abeysinghe
    Created: Wed, 6 Oct 2004 8:49 PM
I have other thoughts on using ref counts to resolve this issue.
Would we not need locking in order to achieve thread safety with ref counts? Our effort is
to leave the thread specific locking to the user, and not use any thread specific stuff in
the core of Axis C++. Hence the  lib level init/uninit with Axis class (see my earlier comment)
would be more appropriate.
View this comment:

View the issue:

Here is an overview of the issue:
        Key: AXISCPP-189
    Summary: Stub falls over after first stub has been deleted
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Axis-C++
             Basic Architecture
             1.3 Final

   Reporter: Mark Whitlock

    Created: Wed, 6 Oct 2004 6:09 AM
    Updated: Wed, 6 Oct 2004 8:49 PM

The first Call to be created remembers that it issued initialize_module and issues uninitialize_module
in its destructor. Other Call objects don't issue initialize_module. If other Call objects
are used after the first Call has been deleted, uninitialize_module will have been called
and they will fall over. There should be a reference count of the number of Call objects and
the *last* one should issue uninitialize_module, not the one that issued initialize_module.
This problem will happen for Stubs and generated stubs, since a generated stub has a Stub
and a Stub has a Call.

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message