[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: duplicate calls to web service



Hello,


On 2/14/2011 2:53 PM, Kim Gibson wrote:
> I did try timing the request with a browser, and didn't receive a
> response there, either.

Ahh, okay... to me that makes it clear that the problem is on the 
server-side, and that nothing I do to HTTPAPI will help.

That's good to know, because the problem seemed to start when you 
switched to the BETA version... I was worried that you'd found some 
regression.  But if the browsers have the same problem, it must be on 
the server side.


> A phone call to the web service tech support people, and apparently
> the web service was down for a period of time this morning. All 33
> requests made this morning would have waited 10 minutes in vain for a
> response. But if the wait state doesn't take up any resources that
> shouldn't be a problem.

They shouldn't use any (measurable) amount of CPU.  They should just sit 
at SELW status (in WRKACTJOB) waiting for the network.

Obviously, they still use memory, et al.  (But I'm sure you knew that.)


> It sounds as if I may have to figure out a way to resubmit the failed
> requests at another time of day, in the hopes of getting a response.

The "resubmit" might be where you're ending up with duplicates.  and 
that's a problem!  IMHO, the server should be using something like 
commitment control.  It should wait until it's able to successfully send 
you a '200' response, and response XML document, without any errors 
before it actually commits the transaction.  If it fails to send you 
this response, it should roll back the transaction.

But it sounds like it's recording the transaction (and committing it) 
and when that is successful, it's sending your response.  Problem is, 
for some reason, it's failing to send that response.  So you re-send the 
transaction (since you didn't get a successful response) but it causes 
duplication.

It would all be fine if the response communication worked -- but 
apparently it isn't...?
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------