You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Chris Mattmann <ch...@jpl.nasa.gov> on 2006/05/09 18:19:43 UTC
CommonsTransportFactory not thread-safe?
Hi Folks,
My name is Chris Mattmann: I'm a software engineer at JPL and a proud user
of your excellent software! Kudos, I really like it a lot. I had sort of a
newbie question, though and I was hoping that one of the fine developers on
this list could answer it for me.
I see that there is no way to really set a timeout on the XML-RPC call in
any of the examples on the web. Perusing through the code (I'm using the
2.1-dev version), I noticed that there was a means in the TransportFactory
called CommonsTransportFactory to set a timeout. Basically let me explain to
you the situation that I'm having.
I have an XML-RPC file manager service that is responding to many
requests to ingest files. The file manager service is basically a set of
higher level wrapper operations around atomic lower level operations. Most
of the methods that I expose from the file manager service are not
synchronized, however the ingest method is. So, what I'm experiencing (I
believe) is certain requests over XML-RPC from a client to my file manager
service are getting dropped out because the file manager service blocks on
ingest.
My colleague mentioned to me he had experienced something similar on a
different project, and that it was due to XML-RPC timing out waiting for the
response from the server. So, I'm looking for a way to set the timeout on
the response from the XML-RPC server. I think that something like:
CommonsTransportFactory transportFactory = new CommonsTransportFactory(url);
TransportFactory.setTimeout(my_timeout);
XmlRpcClient client_ = new XmlRpcClient(url, transportFactory);
Should work, but one thing that worries me is that the javadoc mentions that
this class is not "thread safe". I'm wondering exactly what this means. Does
this mean that I can't use the XmlRpcClient that uses a
CommonsTransportFactory in a threaded application? If so, are there any
other options out there for me to get the timeout set. This is a critical
feature that I really need (make or break, basically).
Please, let me know and thanks again for your help!
Cheers,
Chris Mattmann
______________________________________________
Chris A. Mattmann
Chris.Mattmann@jpl.nasa.gov
Staff Member
Modeling and Data Management Systems Section (387)
Data Management Systems and Technologies Group
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
Re: CommonsTransportFactory not thread-safe?
Posted by Henri Gomez <he...@gmail.com>.
Could you consider using XML RPC 3.0 (trunk), instead ?
2006/5/9, Chris Mattmann <ch...@jpl.nasa.gov>:
> Hi Henri,
>
> Thanks very much for your response. I tried using your example code below
> but there is not a setConnectionTimeout method in the HttpClient class in
> xmlrpc-2.1.-dev. There is, however, a setTimeout method.
>
> Right now my code looks like this:
>
> CommonsXmlRpcTransportFactory transportFactory = new
> CommonsXmlRpcTransportFactory(
> url);
> transportFactory.setConnectionTimeout(connectionTimeout);
> transportFactory.setTimeout(requestTimeout);
> fClient = new XmlRpcClient(url, transportFactory);
>
> Is the above the right approach?
>
> Also, can you comment on what it means in the javadoc for 2.1-dev where it
> says that the CommonsXmlRpcTransportFactory isn't thread safe?
>
> Thanks very much, again.
>
> Cheers,
> Chris
>
>
>
> On 5/9/06 11:54 AM, "Henri Gomez" <he...@gmail.com> wrote:
>
> > Well on latest trunk, future 3.0a2, I added support for request and
> > connection timeout yesterday.
> >
> > BTW, in XML RPC 2.0, I used to set timeout like this :
> >
> > httpTransport = new HttpClient();
> >
> > httpTransport.setConnectionTimeout(lTimeOut);
> > httpTransport.setTimeout(lTimeOut);
> > transport = new CommonsXmlRpcTransport(pSettings.getUrl(),
> > httpTransport);
> > transport.setGzip(true);
> > transport.setHttp11(true);
> >
> > Hope it will help you
> >
> > 2006/5/9, Chris Mattmann <ch...@jpl.nasa.gov>:
> >> Hi Folks,
> >>
> >> My name is Chris Mattmann: I'm a software engineer at JPL and a proud user
> >> of your excellent software! Kudos, I really like it a lot. I had sort of a
> >> newbie question, though and I was hoping that one of the fine developers on
> >> this list could answer it for me.
> >>
> >> I see that there is no way to really set a timeout on the XML-RPC call in
> >> any of the examples on the web. Perusing through the code (I'm using the
> >> 2.1-dev version), I noticed that there was a means in the TransportFactory
> >> called CommonsTransportFactory to set a timeout. Basically let me explain to
> >> you the situation that I'm having.
> >>
> >> I have an XML-RPC file manager service that is responding to many
> >> requests to ingest files. The file manager service is basically a set of
> >> higher level wrapper operations around atomic lower level operations. Most
> >> of the methods that I expose from the file manager service are not
> >> synchronized, however the ingest method is. So, what I'm experiencing (I
> >> believe) is certain requests over XML-RPC from a client to my file manager
> >> service are getting dropped out because the file manager service blocks on
> >> ingest.
> >>
> >> My colleague mentioned to me he had experienced something similar on a
> >> different project, and that it was due to XML-RPC timing out waiting for the
> >> response from the server. So, I'm looking for a way to set the timeout on
> >> the response from the XML-RPC server. I think that something like:
> >>
> >> CommonsTransportFactory transportFactory = new CommonsTransportFactory(url);
> >> TransportFactory.setTimeout(my_timeout);
> >> XmlRpcClient client_ = new XmlRpcClient(url, transportFactory);
> >>
> >> Should work, but one thing that worries me is that the javadoc mentions that
> >> this class is not "thread safe". I'm wondering exactly what this means. Does
> >> this mean that I can't use the XmlRpcClient that uses a
> >> CommonsTransportFactory in a threaded application? If so, are there any
> >> other options out there for me to get the timeout set. This is a critical
> >> feature that I really need (make or break, basically).
> >>
> >> Please, let me know and thanks again for your help!
> >>
> >> Cheers,
> >> Chris Mattmann
> >>
> >> ______________________________________________
> >> Chris A. Mattmann
> >> Chris.Mattmann@jpl.nasa.gov
> >> Staff Member
> >> Modeling and Data Management Systems Section (387)
> >> Data Management Systems and Technologies Group
> >>
> >> _________________________________________________
> >> Jet Propulsion Laboratory Pasadena, CA
> >> Office: 171-266B Mailstop: 171-246
> >> _______________________________________________________
> >>
> >> Disclaimer: The opinions presented within are my own and do not reflect
> >> those of either NASA, JPL, or the California Institute of Technology.
> >>
> >>
> >>
>
> ______________________________________________
> Chris A. Mattmann
> Chris.Mattmann@jpl.nasa.gov
> Staff Member
> Modeling and Data Management Systems Section (387)
> Data Management Systems and Technologies Group
>
> _________________________________________________
> Jet Propulsion Laboratory Pasadena, CA
> Office: 171-266B Mailstop: 171-246
> _______________________________________________________
>
> Disclaimer: The opinions presented within are my own and do not reflect
> those of either NASA, JPL, or the California Institute of Technology.
>
>
>
Re: CommonsTransportFactory not thread-safe?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 5/9/06, Chris Mattmann <ch...@jpl.nasa.gov> wrote:
> Also, can you comment on what it means in the javadoc for 2.1-dev where it
> says that the CommonsXmlRpcTransportFactory isn't thread safe?
I believe you've been misreading that. A configured
CommonsXmlRpcTransport*Factory* is thread safe. (Configuration on the
fly should not occur, though, but that seems to me to be acceptable.)
The note on thread safety is in the transport itself. Basically it
simply indicates, that a new instance has to be created for any
request. But that's exactly how it is coded.
I understand the note to tell, that a possible performance gain might
be to reuse the transport and, in particular, the commons httpclient
objects. As I do not know, how connection reuse and the like works
within this library, I can't tell you whether that is the case.
Obviously, reliability is more important than performance and so I do
think it will remain the same, at lest for version 2.
Jochen
--
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)
Re: CommonsTransportFactory not thread-safe?
Posted by Chris Mattmann <ch...@jpl.nasa.gov>.
Hi Henri,
Thanks very much for your response. I tried using your example code below
but there is not a setConnectionTimeout method in the HttpClient class in
xmlrpc-2.1.-dev. There is, however, a setTimeout method.
Right now my code looks like this:
CommonsXmlRpcTransportFactory transportFactory = new
CommonsXmlRpcTransportFactory(
url);
transportFactory.setConnectionTimeout(connectionTimeout);
transportFactory.setTimeout(requestTimeout);
fClient = new XmlRpcClient(url, transportFactory);
Is the above the right approach?
Also, can you comment on what it means in the javadoc for 2.1-dev where it
says that the CommonsXmlRpcTransportFactory isn't thread safe?
Thanks very much, again.
Cheers,
Chris
On 5/9/06 11:54 AM, "Henri Gomez" <he...@gmail.com> wrote:
> Well on latest trunk, future 3.0a2, I added support for request and
> connection timeout yesterday.
>
> BTW, in XML RPC 2.0, I used to set timeout like this :
>
> httpTransport = new HttpClient();
>
> httpTransport.setConnectionTimeout(lTimeOut);
> httpTransport.setTimeout(lTimeOut);
> transport = new CommonsXmlRpcTransport(pSettings.getUrl(),
> httpTransport);
> transport.setGzip(true);
> transport.setHttp11(true);
>
> Hope it will help you
>
> 2006/5/9, Chris Mattmann <ch...@jpl.nasa.gov>:
>> Hi Folks,
>>
>> My name is Chris Mattmann: I'm a software engineer at JPL and a proud user
>> of your excellent software! Kudos, I really like it a lot. I had sort of a
>> newbie question, though and I was hoping that one of the fine developers on
>> this list could answer it for me.
>>
>> I see that there is no way to really set a timeout on the XML-RPC call in
>> any of the examples on the web. Perusing through the code (I'm using the
>> 2.1-dev version), I noticed that there was a means in the TransportFactory
>> called CommonsTransportFactory to set a timeout. Basically let me explain to
>> you the situation that I'm having.
>>
>> I have an XML-RPC file manager service that is responding to many
>> requests to ingest files. The file manager service is basically a set of
>> higher level wrapper operations around atomic lower level operations. Most
>> of the methods that I expose from the file manager service are not
>> synchronized, however the ingest method is. So, what I'm experiencing (I
>> believe) is certain requests over XML-RPC from a client to my file manager
>> service are getting dropped out because the file manager service blocks on
>> ingest.
>>
>> My colleague mentioned to me he had experienced something similar on a
>> different project, and that it was due to XML-RPC timing out waiting for the
>> response from the server. So, I'm looking for a way to set the timeout on
>> the response from the XML-RPC server. I think that something like:
>>
>> CommonsTransportFactory transportFactory = new CommonsTransportFactory(url);
>> TransportFactory.setTimeout(my_timeout);
>> XmlRpcClient client_ = new XmlRpcClient(url, transportFactory);
>>
>> Should work, but one thing that worries me is that the javadoc mentions that
>> this class is not "thread safe". I'm wondering exactly what this means. Does
>> this mean that I can't use the XmlRpcClient that uses a
>> CommonsTransportFactory in a threaded application? If so, are there any
>> other options out there for me to get the timeout set. This is a critical
>> feature that I really need (make or break, basically).
>>
>> Please, let me know and thanks again for your help!
>>
>> Cheers,
>> Chris Mattmann
>>
>> ______________________________________________
>> Chris A. Mattmann
>> Chris.Mattmann@jpl.nasa.gov
>> Staff Member
>> Modeling and Data Management Systems Section (387)
>> Data Management Systems and Technologies Group
>>
>> _________________________________________________
>> Jet Propulsion Laboratory Pasadena, CA
>> Office: 171-266B Mailstop: 171-246
>> _______________________________________________________
>>
>> Disclaimer: The opinions presented within are my own and do not reflect
>> those of either NASA, JPL, or the California Institute of Technology.
>>
>>
>>
______________________________________________
Chris A. Mattmann
Chris.Mattmann@jpl.nasa.gov
Staff Member
Modeling and Data Management Systems Section (387)
Data Management Systems and Technologies Group
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
Re: CommonsTransportFactory not thread-safe?
Posted by Henri Gomez <he...@gmail.com>.
Well on latest trunk, future 3.0a2, I added support for request and
connection timeout yesterday.
BTW, in XML RPC 2.0, I used to set timeout like this :
httpTransport = new HttpClient();
httpTransport.setConnectionTimeout(lTimeOut);
httpTransport.setTimeout(lTimeOut);
transport = new CommonsXmlRpcTransport(pSettings.getUrl(),
httpTransport);
transport.setGzip(true);
transport.setHttp11(true);
Hope it will help you
2006/5/9, Chris Mattmann <ch...@jpl.nasa.gov>:
> Hi Folks,
>
> My name is Chris Mattmann: I'm a software engineer at JPL and a proud user
> of your excellent software! Kudos, I really like it a lot. I had sort of a
> newbie question, though and I was hoping that one of the fine developers on
> this list could answer it for me.
>
> I see that there is no way to really set a timeout on the XML-RPC call in
> any of the examples on the web. Perusing through the code (I'm using the
> 2.1-dev version), I noticed that there was a means in the TransportFactory
> called CommonsTransportFactory to set a timeout. Basically let me explain to
> you the situation that I'm having.
>
> I have an XML-RPC file manager service that is responding to many
> requests to ingest files. The file manager service is basically a set of
> higher level wrapper operations around atomic lower level operations. Most
> of the methods that I expose from the file manager service are not
> synchronized, however the ingest method is. So, what I'm experiencing (I
> believe) is certain requests over XML-RPC from a client to my file manager
> service are getting dropped out because the file manager service blocks on
> ingest.
>
> My colleague mentioned to me he had experienced something similar on a
> different project, and that it was due to XML-RPC timing out waiting for the
> response from the server. So, I'm looking for a way to set the timeout on
> the response from the XML-RPC server. I think that something like:
>
> CommonsTransportFactory transportFactory = new CommonsTransportFactory(url);
> TransportFactory.setTimeout(my_timeout);
> XmlRpcClient client_ = new XmlRpcClient(url, transportFactory);
>
> Should work, but one thing that worries me is that the javadoc mentions that
> this class is not "thread safe". I'm wondering exactly what this means. Does
> this mean that I can't use the XmlRpcClient that uses a
> CommonsTransportFactory in a threaded application? If so, are there any
> other options out there for me to get the timeout set. This is a critical
> feature that I really need (make or break, basically).
>
> Please, let me know and thanks again for your help!
>
> Cheers,
> Chris Mattmann
>
> ______________________________________________
> Chris A. Mattmann
> Chris.Mattmann@jpl.nasa.gov
> Staff Member
> Modeling and Data Management Systems Section (387)
> Data Management Systems and Technologies Group
>
> _________________________________________________
> Jet Propulsion Laboratory Pasadena, CA
> Office: 171-266B Mailstop: 171-246
> _______________________________________________________
>
> Disclaimer: The opinions presented within are my own and do not reflect
> those of either NASA, JPL, or the California Institute of Technology.
>
>
>