Return-Path: X-Original-To: apmail-axis-c-user-archive@www.apache.org Delivered-To: apmail-axis-c-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 36A39903C for ; Fri, 13 Jan 2012 20:19:10 +0000 (UTC) Received: (qmail 28684 invoked by uid 500); 13 Jan 2012 20:19:07 -0000 Delivered-To: apmail-axis-c-user-archive@axis.apache.org Received: (qmail 28157 invoked by uid 500); 13 Jan 2012 20:19:06 -0000 Mailing-List: contact c-user-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache AXIS C User List" Delivered-To: mailing list c-user@axis.apache.org Received: (qmail 27631 invoked by uid 99); 13 Jan 2012 20:19:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2012 20:19:06 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=HTML_FONT_FACE_BAD,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alex.mantaut@intraway.com designates 209.85.212.173 as permitted sender) Received: from [209.85.212.173] (HELO mail-wi0-f173.google.com) (209.85.212.173) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2012 20:19:00 +0000 Received: by wibhm11 with SMTP id hm11so871267wib.32 for ; Fri, 13 Jan 2012 12:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intraway.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=EbLi4iDj1FvuEWDueXbku/oWPfwkpNWZp808+PIOSBQ=; b=RTpan6fBTzRNJn2WO1rRNE5U+6DQm7RgE/C4dRYPtSNOxWwBpqwXR85YG4YwmPFfI3 MN1mYEetzKaPtOEx6By8Ym+oRS24oZ2E0ikAh4XF9sOuuIECx6uw4VH7FYGqv7bUYQR1 oyr4Y8mQ2mWgm9XT7LexDjpOXjjhTSOxY0SxA= MIME-Version: 1.0 Received: by 10.180.77.136 with SMTP id s8mr4562654wiw.0.1326485902219; Fri, 13 Jan 2012 12:18:22 -0800 (PST) Received: by 10.216.37.21 with HTTP; Fri, 13 Jan 2012 12:18:22 -0800 (PST) Date: Fri, 13 Jan 2012 17:18:22 -0300 Message-ID: Subject: Crash when reusing svc_client with non-blocking call From: Alex Mantaut To: c-user@axis.apache.org Content-Type: multipart/alternative; boundary=f46d043c80ee0058a404b66e91da --f46d043c80ee0058a404b66e91da Content-Type: text/plain; charset=ISO-8859-1 Hi all, I'm performing a stress test on AXIS2C, sending multiple Asynchronous request from a client to a service. I'm using an instance of svc_client to send multiple non_blocking requests to a service, but after the request I lock the thread to wait for the callback on complete to finish... The callback unlocks the mutex, wich unlocks the 1st thread. The code is similar to this: mutex.lock(); for(i=0;i<10;i++) { axis2_svc_client_send_receive_ non_blocking (svc_client_, env, payload, callback); mutex.lock(); } mutex.unlock(); echo_callback_on_complete(struct axis2_callback* callback, const axutil_env_t* env) { [does a bunch of stuff] mutex.unlock(); return status; } The thing is when it tries to send a second request it fails with segmentation fault... After some debugging, I found that some of the callback resources weren't completly deallcated when finishing callback_on_complete(), wich somehow makes the next send request cause a segmentation fault... Looking in google I found this https://issues.apache.org/jira/browse/AXIS2C-1551, and it looks like my issue... Somebody did fix this? is there a workaround I could use to know when the callback resources have been released? -- -- Mantaut Alex Intraway Corp. +54 (11) 6040-4000 MSN: alex.mantaut@intraway.com Visit our website at http://www.intraway.com Proud to be an ISO 9001:2008 certified company --f46d043c80ee0058a404b66e91da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,
=A0 =A0 =A0 I'm performing a stress test on AXIS2C, sending multiple Asynchronous request from a client to a service.

=A0I'm using an instance of svc_client to send multiple non_blocking re= quests
to a service, but after the request I lock the thread to wait for the
callback on complete to finish... The callback unlocks the mutex, wich
unlocks the 1st thread.

The code is similar to this:

mutex.lock();
for(i=3D0;i<10;i++)
{
=A0 =A0 =A0 =A0axis2_svc_client_send_receive_
non_blocking = (svc_client_,
env, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 payload, callback);
=A0 =A0 =A0 =A0 mutex.lock();
}
mutex.unlock();


echo_callback_on_complete(struct axis2_callback* callback,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const axutil_env_t* =A0= =A0 =A0env)
{
[does a bunch of stuff]
=A0 =A0 =A0 =A0 mutex.unlock();
=A0 =A0 =A0 =A0 =A0return status;
=A0}

The thing is when it tries to send a second request it fails with
segmentation fault... After some debugging, I found that some of the
callback resources weren't completly deallcated when finishing
callback_on_complete(), wich somehow makes the next send request cause a segmentation fault...

Looking in google I found this
https://issues.apache.org/jira/browse/AXIS2C-1551, and it looks li= ke my
issue... Somebody did fix this? is there a workaround I could use to know when the callback resources have been released?


--
--
Mantaut Alex
Intraway Corp.=A0

+54 (11) 6040-4000=A0=A0
MSN: alex.mantaut@intraway.com
<= div>
Visit our website= at=A0ht= tp://www.intraway.com
Proud to be an ISO 9001:2008 certified company

--f46d043c80ee0058a404b66e91da--