We have a system that connects to a second system via sockets, queries it and after some time (sometimes as long as 1 minute) returns some answers.
From time to time the agent hangs when performing this communcation showing errors:
WTA: WebWrite() failed during npp_send with error: -70 size: 344 sentbytes 0 retrycount 0. (6404)
WTA: WebWrite() failed during npp_send with error: -70 size: 344 sentbytes 0 retrycount 1.
... and then on to ....
WTA: WebWrite() failed during npp_send with error: -70 size: 344 sentbytes 0 retrycount 10.
WTA: npp_send() failed while sending terminate message! Error: -70. (6397)
WTA: Failed to notify broker of state information! (6400)
before finally staying "BUSY" until the process is killed. If we don't keep watch this will during the course of the day finally busify all our agents rendering the system useless.
ID 21009 in the Progress KB states that this can happen if the user (among other things) presses stop in the browser. Not very unlikely after waiting more than a minute. There's also a suggestion setting the retry value lower. But the problem here isn't that there's errors - the problem is that the agent doesn't but it self in AVAILABLE state.
Hang in there if you've read this far. Soon done...
In the core of our sockethandling is a loop:
REPEAT:
WAIT-FOR READ-RESPONSE OF hSocket PAUSE 2.
RUN readResponse.
IF lEndFlag THEN LEAVE.
IF ETIME > 65000 THEN DO:
LEAVE. /* 65 seconds elapsed and no trailer received - bail out! */
END.
/* Insert solution here */
END.
My main idea to solve this is to check for browser status, if its doable. If I could check the state of the browser in every iteration of the loop I could bail out if stopped. Does anyone know if this is possible or do you have other suggestions?
Thanks for taking the time to read this!
Hi Jens,
What version of Webspeed are you using? What webserver are you using and on what platform?
Generally a wait-for in a Webspeed application are not a good thing (as you can see). Because of the long delay the user's web browser either times out or the user presses stop. Depending on the webserver, the webserver will often terminate the cgiip.exe process (which is also called the messenger) causing the below error messages to occur in the log file.
There is no way to check for browser status. Try looking into an AJAX style application in which you give feedback to the user in the form of an animation or something to discourage them from clicking stop.
Sorry, of course I should have written down.
Apache 1.3.x, OpenEdge 10.1A on Solaris 10.
The WAIT-FOR statement is a requirement. Otherwise the core loop will occupy 100% CPU if for some reason the end of the response can't be read. And I do prefer a deadlock before a spinlock.
This is something you may be able to solve with AJAX.
I'm sure there are a bunch of ways you could do it, but here's one. The WebSpeed agent receives the http request and processes it as normal up to the point of doing the socket connection.
The WebSpeed agent then makes an asynchronous AppServer request to a newly define AppServer The new AppServer had a simple program that does the existing socket request, waits for the answer and when it arrives, writes the answer into a database table (that is available to both the AppServer and WebSpeed agents).
In the mean time, since the AppServer request was async, the WebSpeed agent has finished it's job and sent back a message like: "Processing - please wait..." (with associated animated image, so that the user "sees" that it's doing something).
Part of this response would kick off a JavaScript timer in the browser that makes an AJAX request (to WebSpeed) every x seconds. This request would simply look in the database table to see if the AppServer job has finished or not and if so, what the response was. If it's finished, you could send back as much HTML/XML/JSON/... to the client as required to show the user what they need to see.
But what if I for different reasons don't want to do it in AJAX?
The problem I want to focus on here the agents hanging. There must be some kind of work around for this. It might be something else going wrong - I'm actually just guessing (with some pointers from the Progress KB) agent hangs because of users pressing STOP.
Does this help: http://progress.atgnow.com/esprogress/control.do?directSolutionLink=1&docPropValue=p152#
All the references I've found to this don't seem to indicate that a user pressing STOP should actually cause the agent to hang - produce the error yes, but not hang.
I have also found a possibly related bug number 20060203-013 which was resolved in 10.1A01.
I neither of the above help, I'd definitely talk to Tech Support.
Have you tried to query hSocket:CONNECTED() in the loop? Normally when one of the parties leave, the socket closes. I don't know if you can detect that in the ABL.
Have you tried to set a READ-timeout on the sock using the SET-SOCKET-OPTION?
Have you tried to add the "ON STOP"-phrase to the REPEAT-loop? I think the problem might be that the WAIT-FOR never stops on error. So you might want to try to add another condition to it, basically a logical expression you can influence you wait for. You can wait for CLOSE-PROCEDURE and fire it in the STOP/ERROR condition, so the WAIT-FOR terminates...
My main idea to solve this is to check for browser
status, if its doable. If I could check the state of
the browser in every iteration of the loop I could
bail out if stopped. Does anyone know if this is
possible or do you have other suggestions?
I don't think that's possible. Also the browser expects HTTP-trafic on it's socket, so you shouldn't be posting anything on it.
It's pretty simple to do a callback in the browser. It's just some JavaScript calling a web-page. See http://www.w3schools.com/ajax/ajax_httprequest.asp. There are some scripts out there that create a wrapper around this xmlhttp-object to make it portable.
Can't get your link to work.
Yes, when reading again I see it states that an error can occur but hanging isn't mentioned. Anyway I think I'll upgrade to 101A01 and see if it solves it.
Can't get your link to work.
Yes, when reading again I see it states that an error can occur but hanging isn't mentioned. Anyway I think I'll upgrade to 101A01 and see if it solves it.