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/08/18 15:55:51 UTC
[jira] Created: (AXISCPP-130) Client memory problems with globals
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-130
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-130
Summary: Client memory problems with globals
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Basic Architecture
Versions:
1.3 Beta
Assignee:
Reporter: Mark Whitlock
Created: Wed, 18 Aug 2004 6:55 AM
Updated: Wed, 18 Aug 2004 6:55 AM
Description:
The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
invokes web services from multiple threads at the same time would fail for the same reason.
g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
---------------------------------------------------------------------
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-130) Client memory problems with globals
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXISCPP-130?page=comments#action_55669 ]
Samisa Abeysinghe commented on AXISCPP-130:
-------------------------------------------
Are we happy with the use of globles with the current codebase?
Are we looking for further improvements in this space?
> Client memory problems with globals
> -----------------------------------
>
> Key: AXISCPP-130
> URL: http://nagoya.apache.org/jira/browse/AXISCPP-130
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Beta
> Reporter: Mark Whitlock
>
> The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
> invokes web services from multiple threads at the same time would fail for the same reason.
> g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
--
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-130) Client memory problems with globals
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Samisa Abeysinghe
Created: Wed, 29 Sep 2004 4:22 AM
Body:
With the latest Axis class (in include/axis/Axis.h) initialize and terminate methods could be used to safely allocate/release memory for globles outside of stubs in a threaded application.
It is gaurenteed that these methods are called once, in case several stubs are created.
Also, it is also possible to create a single stub without calling Axis::initialize and the stub will make sure the globles are allocated and deallocated (thus making sure backward compatibility)
However, the globles still remain and the ideal solution would be to eliminate these globles using Axis class as the holder of globle members (and making sure Axis class is a singleton). This could be done as part of proposed refactoring for 1.4.
Although the possible problems due to globles are solved, I keep this issue open as the globles are still there.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-130?page=comments#action_53494
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-130
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-130
Summary: Client memory problems with globals
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Basic Architecture
Versions:
1.3 Beta
Assignee:
Reporter: Mark Whitlock
Created: Wed, 18 Aug 2004 6:55 AM
Updated: Wed, 29 Sep 2004 4:22 AM
Description:
The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
invokes web services from multiple threads at the same time would fail for the same reason.
g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
---------------------------------------------------------------------
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-130) Client memory problems with globals
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-130?page=comments#action_58304 ]
Samisa Abeysinghe commented on AXISCPP-130:
-------------------------------------------
We still do have globles; but are not facing problems with them as far as we know.
Hence can I say that we are happy about the use of globles in current codebase and close this out?
> Client memory problems with globals
> -----------------------------------
>
> Key: AXISCPP-130
> URL: http://issues.apache.org/jira/browse/AXISCPP-130
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Beta
> Reporter: Mark Whitlock
>
> The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
> invokes web services from multiple threads at the same time would fail for the same reason.
> g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
--
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-130) Client memory problems with globals
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Samisa Abeysinghe
Created: Thu, 9 Sep 2004 3:02 AM
Body:
I updated the code to call ModuleUnInitialize() on client side to prevent memory leaks by making sure the globals get deleted.
Threading issues due to the use of the globle g_pSerializerPool is yet to be fixed.
However the thSafeTest in the tests folder does work without problems with the axis transport.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-130?page=comments#action_52993
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-130
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-130
Summary: Client memory problems with globals
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Basic Architecture
Versions:
1.3 Beta
Assignee:
Reporter: Mark Whitlock
Created: Wed, 18 Aug 2004 6:55 AM
Updated: Thu, 9 Sep 2004 3:02 AM
Description:
The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
invokes web services from multiple threads at the same time would fail for the same reason.
g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
---------------------------------------------------------------------
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] Closed: (AXISCPP-130) Client memory problems with globals
Posted by "Adrian Dick (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-130?page=all ]
Adrian Dick closed AXISCPP-130:
-------------------------------
> Client memory problems with globals
> -----------------------------------
>
> Key: AXISCPP-130
> URL: http://issues.apache.org/jira/browse/AXISCPP-130
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Beta
> Reporter: Mark Whitlock
>
> The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
> invokes web services from multiple threads at the same time would fail for the same reason.
> g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
--
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-130) Client memory problems with globals
Posted by "Mark Whitlock (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXISCPP-130?page=comments#action_55678 ]
Mark Whitlock commented on AXISCPP-130:
---------------------------------------
I will get rid of the g_pAT global variable as part of my work on trace. I intend to make trace methods static. The advantage of this is that it makes startup trace (trace before axiscpp.conf is read in) easier to implement. Also it means that g_pAT will not need to be passed to the transport/xmlparser libraries to enable them for trace.
> Client memory problems with globals
> -----------------------------------
>
> Key: AXISCPP-130
> URL: http://nagoya.apache.org/jira/browse/AXISCPP-130
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Beta
> Reporter: Mark Whitlock
>
> The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
> invokes web services from multiple threads at the same time would fail for the same reason.
> g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
--
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] Resolved: (AXISCPP-130) Client memory problems with globals
Posted by "John Hawkins (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-130?page=history ]
John Hawkins resolved AXISCPP-130:
----------------------------------
Resolution: Fixed
I'm going to resolve this as apparently no one else has a view !
> Client memory problems with globals
> -----------------------------------
>
> Key: AXISCPP-130
> URL: http://issues.apache.org/jira/browse/AXISCPP-130
> Project: Axis-C++
> Type: Bug
> Components: Basic Architecture
> Versions: 1.3 Beta
> Reporter: Mark Whitlock
>
> The SerializerPool is a global referenced from g_pSerializerPool and is new'ed during the Call constructor. A client application that creates stubs up front and then uses them later would fail because the 2nd time the Call constructor is invoked it would overwrite the globals the 1st Call constructor set up. An application that
> invokes web services from multiple threads at the same time would fail for the same reason.
> g_pSerializerPool gets deleted in ModuleUnInitialize() which is only called from the SimpleAxisServer. So a client application that creates, uses and deletes Stubs leaks memory since these globals never get deleted.
--
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