The code in the exception clause of:
public void write (byte[] request) throws IOException
in XmlRpcClientLite does not seem to be effective in handling keep-alive
timeouts. The solution that works for me is to repeat the call to:
Object execute (String method,
Hi all,
Well after listening to all this discussion I just had to
pitch in. I have been using XML-RPC for a long time and worked with
implementations in perl, java(helma/apache) and c++ (Eric Kid). I
must say that it is simple and very interoperable. This is due to,
at least in par
I wouldn't say that removing null support has made XML-RPC "useless" for
people who previously relied on it. I'm sure it is causing some
headaches. It would be interesting to hear how people work around this.
I know I'm to blame for implementing this feature when it was only a
proposal, and re
Here's my view on the frozen spec issue, as well as some background info
for those who are relatively new to XML-RPC.
As far as I know, the primary reason for Dave wanting the spec frozen is
to not have too much of his small company's manpower tied up to
following a moving spec. What he wants
Jim Redman <[EMAIL PROTECTED]> writes:
> The code in the exception clause of:
>
> public void write (byte[] request) throws IOException
>
> in XmlRpcClientLite does not seem to be effective in handling
> keep-alive timeouts. The solution that works for me is to repeat the
> call to:
>
>
Thanks Jim. One problem I see with your solution is that it retries on
*every* exception, which is not what we want (or do we?). I'll give it a
try.
Hannes
Jim Redman wrote:
>
> The code in the exception clause of:
>
> public void write (byte[] request) throws IOException
>
> in XmlR
Hannes Wallnöfer <[EMAIL PROTECTED]> writes:
> Here's my view on the frozen spec issue, as well as some background
> info for those who are relatively new to XML-RPC.
>
> As far as I know, the primary reason for Dave wanting the spec frozen
> is to not have too much of his small company's manpowe
On 2002.02.27 08:43:34 -0700 Hannes Wallnöfer wrote:
> Thanks Jim. One problem I see with your solution is that it retries on
> *every* exception, which is not what we want (or do we?). I'll give it a
> try.
I'm not sure that there is sufficient information at this point to
determine whether
Jim Redman <[EMAIL PROTECTED]> writes:
> I have no idea - I don't use the XmlRpcClient directly, only the Lite
> so I don't know the behavior of the XmlRpcClient in this case.
public class XmlRpcClientLite
extends XmlRpcClient
hannes 02/02/27 10:29:19
Modified:src/java/org/apache/xmlrpc XmlRpcClientLite.java
Log:
Fixed a bug with keepalive connections reported by Jim Redman <[EMAIL PROTECTED]>
A timed out keepalive connection wasn't detected because the exception was thrown
not when trying to send th
Jim,
I just committed a fix for the problem to CVS. The solution I used is
slightly different from yours: Instead of the whole LiteWorker.execute()
method, only the sending of the request and the parsing of the response
headers are put into a try-retry wrapper. Otherwise, we'd retry to call
t
Dan,
On 2002.02.27 11:10:10 -0700 Daniel Rall wrote:
> Jim Redman <[EMAIL PROTECTED]> writes:
>
> > I have no idea - I don't use the XmlRpcClient directly, only the Lite
> > so I don't know the behavior of the XmlRpcClient in this case.
>
> public class XmlRpcClientLite
> extends XmlRpcClie
Jim Redman wrote:
> Dan,
>
> On 2002.02.27 11:10:10 -0700 Daniel Rall wrote:
>
>> Jim Redman <[EMAIL PROTECTED]> writes:
>>
>> > I have no idea - I don't use the XmlRpcClient directly, only the Lite
>> > so I don't know the behavior of the XmlRpcClient in this case.
>>
>> public class XmlRpcClien
13 matches
Mail list logo
