Return-Path: 
 <axis-c-dev-return-14611-apmail-ws-axis-c-dev-archive=ws.apache.org@ws.apache.org>
Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org
Received: (qmail 58195 invoked from network); 9 Aug 2007 10:30:04 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 9 Aug 2007 10:30:04 -0000
Received: (qmail 33791 invoked by uid 500); 9 Aug 2007 10:30:02 -0000
Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org
Received: (qmail 33738 invoked by uid 500); 9 Aug 2007 10:30:02 -0000
Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:axis-c-dev-help@ws.apache.org>
list-unsubscribe: <mailto:axis-c-dev-unsubscribe@ws.apache.org>
List-Post: <mailto:axis-c-dev@ws.apache.org>
List-Id: "Apache AXIS C Developers List" <axis-c-dev.ws.apache.org>
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Delivered-To: mailing list axis-c-dev@ws.apache.org
Received: (qmail 33720 invoked by uid 99); 9 Aug 2007 10:30:02 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2007 03:30:02 -0700
X-ASF-Spam-Status: No, hits=-99.3 required=10.0
	tests=ALL_TRUSTED,FRT_LEVITRA
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2007 10:30:03 +0000
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id E345671413F
	for <axis-c-dev@ws.apache.org>; Thu,  9 Aug 2007 03:29:42 -0700 (PDT)
Message-ID: <13735039.1186655382926.JavaMail.jira@brutus>
Date: Thu, 9 Aug 2007 03:29:42 -0700 (PDT)
From: "Rock Wang (JIRA)" <jira@apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Updated: (AXIS2C-664) It seems that axis2/c lib has an upper
 limitation on the number of service client that have been created.
In-Reply-To: <636984.1186655142695.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org


     [ https://issues.apache.org/jira/browse/AXIS2C-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rock Wang updated AXIS2C-664:
-----------------------------

    Description: 
It seems that axis2/c lib has an upper limitation on the number of service client object that have ever been created. 

Note that I used the the word "have ever",  which means the limitation is not on the number of client that are simultaneously active, but on the total number of clients that have ever been created, including those already freed.

The following program can be used to generate the problem. In my Visual C++ 2005, it incurs an "Unhandled Win32 exception".  And to make more strange, using "Ctrl-F5"(start debugging) to run the program can make the exception occurs more easily than using just "F5"(start without debugging). I mean more "early" or more "rapidly".

#include <iostream>
#include <axis2_util.h>
#include <axis2_client.h>

using namespace std;

int main() {
	axutil_env_t* env = axutil_env_create_all("hello_client.log", AXIS2_LOG_LEVEL_TRACE);

	const int TIMES = 1000;
	for(int i = 1; i <= TIMES; ++i) {
		cout << i << endl;
		axis2_svc_client_t* svc_client = axis2_svc_client_create(env, "axis2_repository");
		axis2_svc_client_free(svc_client, env);
	}

	axutil_env_free(env);
	return 0;
}

Using ctrl-F5, the program terminated with that exception when i becomes only 10.
 I really feel that this code should not fail, because every client object is freed before creating a new one, which means, there is always at most only one client object living in my program.

  was:
It seems that axis2/c lib has an upper limitation on the number of service client object that have ever been created. 

Note that I used the the word "have ever",  which means the limitation is not on the number of client that are simultaneously active, but on the total number of clients that have ever been created, including those already freed.

The following program can be used to generate the problem. In my Visual C++ 2005, it incurs an "Unhandled Win32 exception".  And to make more strange, using "Ctrl-F5"(start debugging) to run the program can make the exception occurs more easily than using just "F5"(start without debugging).

#include <iostream>
#include <axis2_util.h>
#include <axis2_client.h>

using namespace std;

int main() {
	axutil_env_t* env = axutil_env_create_all("hello_client.log", AXIS2_LOG_LEVEL_TRACE);

	const int TIMES = 1000;
	for(int i = 1; i <= TIMES; ++i) {
		cout << i << endl;
		axis2_svc_client_t* svc_client = axis2_svc_client_create(env, "axis2_repository");
		axis2_svc_client_free(svc_client, env);
	}

	axutil_env_free(env);
	return 0;
}

I really feel that this code should not fail, because every client object is freed before creating a new one, which means, there is always at most only one client object living in my program.


> It seems that axis2/c lib has an upper limitation on the number of service client that have been created.
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-664
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-664
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: core/clientapi
>    Affects Versions: 1.0.0
>         Environment: Windodw Server 2003, English Version, Microsoft Visual C++.net 2005
>            Reporter: Rock Wang
>            Priority: Critical
>
> It seems that axis2/c lib has an upper limitation on the number of service client object that have ever been created. 
> Note that I used the the word "have ever",  which means the limitation is not on the number of client that are simultaneously active, but on the total number of clients that have ever been created, including those already freed.
> The following program can be used to generate the problem. In my Visual C++ 2005, it incurs an "Unhandled Win32 exception".  And to make more strange, using "Ctrl-F5"(start debugging) to run the program can make the exception occurs more easily than using just "F5"(start without debugging). I mean more "early" or more "rapidly".
> #include <iostream>
> #include <axis2_util.h>
> #include <axis2_client.h>
> using namespace std;
> int main() {
> 	axutil_env_t* env = axutil_env_create_all("hello_client.log", AXIS2_LOG_LEVEL_TRACE);
> 	const int TIMES = 1000;
> 	for(int i = 1; i <= TIMES; ++i) {
> 		cout << i << endl;
> 		axis2_svc_client_t* svc_client = axis2_svc_client_create(env, "axis2_repository");
> 		axis2_svc_client_free(svc_client, env);
> 	}
> 	axutil_env_free(env);
> 	return 0;
> }
> Using ctrl-F5, the program terminated with that exception when i becomes only 10.
>  I really feel that this code should not fail, because every client object is freed before creating a new one, which means, there is always at most only one client object living in my program.

-- 
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org