On 4 Dec 2007, at 07:36, Marc Nädele wrote:
Hi Michele,
the state does not matter. The calls to the service are
independent. So the WS implementation on the server does not need
to know anything about the state.
You didn't get my point. The state is your RPCServiceClient instance
(you're doing the same using a stateless WS + static variable).
My problem is that the client application produces bursts of
independend web service calls to the same web service. The user can
load a file where elements are stored. Some of those elements are
converted using a web service depending on their type. Because of
the system architecture the module which wrapps the
RPCServiceClient and which calls the web service can not know how
many elements are converted via the web service because the
conversion of each element is an independent operation. So until
know I create a new RPCServiceClient for every conversion
operation. Since there may be up to 5000 elements which must be
converted in a row, 5000 instances of RPCServiceClient are created
in a short period of time and I run into the described ressource
problems with the sockets.
My concerns are that I keep a living static instance of
RPCServiceClient during the whole lifetime of my application which
may never close open ressources. So my question is what I have to
do when I reuse one instance during the lifetime of the
application. Is it important to initialize and close the instance
for each call or can I just create and initialize the instance once
and then reuse it without using any special method?
Keep using your single instance and clean only when you're done.
I hope this helps to understand the problem.
Thanks
- Marc
Michele
----------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [Axis2] Considerations regarding a static
RPCServiceClient instance
Date: Mon, 3 Dec 2007 17:50:38 +0000
To: [email protected]
Marc,
have you considered making your WS statefull?, Using a static
variable to store the state (i.e. your RPCServiceClient) doesn't
sound a good idea to me.
About your concerns (i.e. resource usage) can you be more specific?
Michele
On 3 Dec 2007, at 17:40, Marc Nädele wrote:
Hi all,
I have some serious problems (like out-of socket errors) with the
RPCServiceClient class when I have a burst of web service calls
very fast in a row and create a new RPCServiceClient instance for
each call. Normally my application creates series of fast web
service calls (to the same web service) in a row like a "burst".
Unfortunately because of the system architecture I don't know in my
module - which implements the web service request - how many
service calls will follow a certain service call. So I can not use
the best solution like creating a RPCServiceClient instance when
the first call to the web service occurs and "shut down" the
RPCServiceClient instance when all requests of this "burst" are
done.
The only solution I currently have is to use a static
RPCServiceClient instance which will be created when the
applciation starts and lives until the application is shut down.
This solution seems to be OK at the first glance but I am afraid
that this will result in some other problems like not freeing
ressources or other ugly side-effects.
Does anyone have some hints what I have to consider if I use a
"static" RPCServiceClient instance and which options or parameters
I should use?
Any help or comment is welcome.
Thanks in advance
- Marc
Mit Live Search: Ihre Stadt in der Vogelperspektive! Erleben Sie
neue Blickwinkel!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Jetzt kostenlos downloaden: 30 Messenger Emoticons!
http://www.messenger-emoticons.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
