You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by ax...@ws.apache.org on 2004/10/06 15:10:31 UTC
[jira] Created: (AXISCPP-189) Stub falls over after first stub has been deleted
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-189
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++
Components:
Basic Architecture
Versions:
1.3 Final
Assignee:
Reporter: Mark Whitlock
Created: Wed, 6 Oct 2004 6:09 AM
Updated: Wed, 6 Oct 2004 6:09 AM
Description:
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.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-189) Stub falls over after first stub has been deleted
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-189?page=comments#action_54654 ]
Samisa Abeysinghe commented on AXISCPP-189:
-------------------------------------------
Are we happy with the platform level Axis::initialize(false); {false to indicate client; true to say its server} and Axis::terminate(); as a solution for this issues? Or are we looking for another solution. (Thread safety concerns leave out refcount)
> Stub falls over after first stub has been deleted
> -------------------------------------------------
>
> Key: AXISCPP-189
> URL: http://issues.apache.org/jira/browse/AXISCPP-189
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Final
> Reporter: Mark Whitlock
> Priority: Minor
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-189) Stub falls over after first stub has been deleted
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXISCPP-189?page=history ]
Samisa Abeysinghe updated AXISCPP-189:
--------------------------------------
Attachment: AXISCPP-189.cpp
This source file creates two stbs and delete one in the mid of the program.
It used Axis::initialize(false); and Axis::terminate(); to init and uninit platform level stuff.
If you do not use those, then the client segfaults. But I think this is a fair enough solution.
Can use this sample with the base.wsdl generated code and either the base sample service of Axis C++ or the echo sample service of Axis Java
> Stub falls over after first stub has been deleted
> -------------------------------------------------
>
> Key: AXISCPP-189
> URL: http://nagoya.apache.org/jira/browse/AXISCPP-189
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Final
> Reporter: Mark Whitlock
> Priority: Minor
> Attachments: AXISCPP-189.cpp
>
> 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:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-189) Stub falls over after first stub has
been deleted
Posted by "Adrian Dick (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-189?page=all ]
Adrian Dick closed AXISCPP-189:
-------------------------------
> Stub falls over after first stub has been deleted
> -------------------------------------------------
>
> Key: AXISCPP-189
> URL: http://issues.apache.org/jira/browse/AXISCPP-189
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Final
> Reporter: Mark Whitlock
> Priority: Minor
> Fix For: 1.3 Final
> Attachments: AXISCPP-189.cpp
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-189) Stub falls over after first stub has been deleted
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Samisa Abeysinghe
Created: Wed, 6 Oct 2004 6:52 AM
Body:
Ref count will definitely solve the problem.
However, if you are going to deal with multiple stubs in the application , with current code,
Axis::initialize(false);
can be used to init the platform prior to starting to deal with Stubs and call
Axis::terminate();
once the Stubs are done with.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-189?page=comments#action_53757
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-189
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++
Components:
Basic Architecture
Versions:
1.3 Final
Assignee:
Reporter: Mark Whitlock
Created: Wed, 6 Oct 2004 6:09 AM
Updated: Wed, 6 Oct 2004 6:52 AM
Description:
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.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AXISCPP-189) Stub falls over after first stub has been deleted
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXISCPP-189?page=history ]
Samisa Abeysinghe resolved AXISCPP-189:
---------------------------------------
Resolution: Fixed
Fix Version: 1.3 Final
The sample code attached works.
See previous comment for more details.
> Stub falls over after first stub has been deleted
> -------------------------------------------------
>
> Key: AXISCPP-189
> URL: http://nagoya.apache.org/jira/browse/AXISCPP-189
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Final
> Reporter: Mark Whitlock
> Priority: Minor
> Fix For: 1.3 Final
> Attachments: AXISCPP-189.cpp
>
> 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:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-189) Stub falls over after first stub has been deleted
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Samisa Abeysinghe
Created: Wed, 6 Oct 2004 8:49 PM
Body:
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:
http://issues.apache.org/jira/browse/AXISCPP-189?page=comments#action_53792
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-189
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++
Components:
Basic Architecture
Versions:
1.3 Final
Assignee:
Reporter: Mark Whitlock
Created: Wed, 6 Oct 2004 6:09 AM
Updated: Wed, 6 Oct 2004 8:49 PM
Description:
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.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira