Hi Tim,
Sorry for the delay in my response, I wasn't able to answer
you sooner... I have a question: What do you mean when you say that
every thread has it's own environment? I'm not entirely sure if that
is correct, I've been using one environment for all the threads,
because the environment has certain synchronization mechanisms such as
a mutex for using the log, etc... But, as I said earlier, I'm not 100%
percent certain that the environment should be used that way... Can
someone confirm which way the environment should be used?
Also, about the bug, I've been using the trunk version of the
code and the bug is still there... Actually, I've trying to solve the
issue, but it is caused by several file openings that are not being
validated which are scattered around the code and only fail under a
lot of load, which makes kind of hard to find them all. The issue is
described in https://issues.apache.org/jira/browse/AXIS2C-1001 and is
still open... Actually I'm very interested in someone finding a patch
for that issue, specially the multiple clients part... (For the
asynchronous calls part I've posted a patch in
https://issues.apache.org/jira/browse/AXIS2C-1584, and I'm waiting to
get a review to see if the bug fix is correct)
best regards
Alex
On Mon, Apr 16, 2012 at 2:32 PM, Tim Stowell <stowe...@gmail.com> wrote:
> Hi,
>
> Thanks for your response! I ended up using two separate request threads,
> each with their own stub/environment etc. and I reuse the
> thread-specific client for each request. It seems to work just fine, I'm
> glad to know others have used the same methodology. Interesting about the
> bug, I'm actually using the 1.7 release candidate maybe it was fixed there?
>
> On Mon, Apr 16, 2012 at 6:39 AM, Alex Mantaut <alex.mant...@intraway.com>
> wrote:
>>
>> Hi Tim,
>> We were using axis2/c in a similar way, reusing the
>> synchronous client to send requests... It seems to work better than
>> spawning one client per request, because every client must allocate
>> several resources (file descriptors, etc) which makes the client
>> slower...
>> However, you must be aware there is a bug when spawning
>> many clients (starting more or less at a 100 clients) that makes the
>> client segfault, because some file openings are not being validated,
>> and when the file descriptors for the process saturate there is an
>> invalid file descriptor somewhere... For those sort of loads it is
>> better to implement some sort of process pool, in order to avoid the
>> bug...
>>
>> Hope it was helpful
>> Regards
>> Alex
>>
>> On Sat, Apr 14, 2012 at 12:51 PM, Tim Stowell <stowe...@gmail.com> wrote:
>> > Hi All,
>> >
>> > I'm currently using Axis2C with wsdl-generated stubs. At the moment I
>> > create
>> > a single stub/environment, then use that to make
>> > multiple synchronous requests one after another, while I recreate the
>> > ADB
>> > objects for each request but I reuse the stub. This seems to work fine
>> > (is
>> > it ok to reuse the same stub?)
>> >
>> > However to make the app more responsive, I'd like to have one or more
>> > threads spawned to send the syncrounous requests. If I create multiple
>> > stubs/environments, can I reuse each one in it's own thread to perform
>> > the
>> > calls, or is there a better way to do this? Thanks!
>>
>>
>>
>> --
>> --
>> Mantaut Alex
>> Intraway Corp.
>>
>> +54 (11) 6040-4000
>> MSN: alex.mant...@intraway.com
>>
>> Visit our website at http://www.intraway.com
>> Proud to be an ISO 9001:2008 certified company
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org
>> For additional commands, e-mail: c-user-h...@axis.apache.org
>>
>
--
--
Mantaut Alex
Intraway Corp.
+54 (11) 6040-4000
MSN: alex.mant...@intraway.com
Visit our website at http://www.intraway.com
Proud to be an ISO 9001:2008 certified company
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org
For additional commands, e-mail: c-user-h...@axis.apache.org
