SstHttpClient - response messages are empty ...

My main working topic in these days are REST based systems - where the backend is Gemstone. One of the best persistency systems I've ever worked with.

Our system is modelled with our own tool - and we produce client source code for Javascript (partially), Python, C# and now we trying VASmalltalk.

As the working horse we use instances of SstHttpClient to communicate with the server and I notice some problems when using this class - some responses are simple: empty. It returns an empty string as an answer and then on my side all this are failing. I've never seen this behaviour with our JS or Python clients.

The stuff begins failing in "SstHttpResponseHeader>>retrieveBytes: n from: stream" where the exception is thrown to signal insufficient data ... then an empty string is returned, the  header is therefore completely empty and the instance of SstHttpResponseHeader is EMPTY. Because of this the SstHttpClient thinks, that the communication is based on Http/0.9 and closes the socket - but delivers an empty string back to the application. For the next request the client opens a new socket again and the request works again.

Very strange is the situation, when I open TWO instances of my client (with the same http-target) in the same image - then the risc of failures are pretty high. Actually when switching between the clients I can be pretty sure, that the next request on the now active client will fail.

Is there anything like this known in the community ...

That's nice -
the good thing is: it has nothing to do with the receiving part - but in errror case, Apache2 does not log any incoming request from the client.

No idea :-(

I looked down up to SciBlockingDispatcher>>callSendWith:with:with:with and printed all needed stuff and - NO error. VASmalltalk believes, that is has sent the stuff - but Apache2 does not log any requests.

I assume that it has to do with the KeepAlive and KeepAliveTimeout of Apache2 ... connecting directly against Gemstone gives a longer life ...

More testing needed

Am Freitag, 2. Oktober 2015 20:41:39 UTC+2 schrieb Marten Feldtmann:

No idea :-(

I looked down up to SciBlockingDispatcher>>callSendWith:with:with:with and printed all needed stuff and - NO error. VASmalltalk believes, that is has sent the stuff - but Apache2 does not log any requests.

The default timeout (at Apache2) is 5 seconds - the timeout I found here is also 5 seconds. It seems, that Apache2 has closed the socket (due to inactivity), but VASmalltalk writes into this socket ... not knowing, that the socket is closed and gets no error ...

Marten

Am Freitag, 2. Oktober 2015 21:14:10 UTC+2 schrieb Marten Feldtmann:

I assume that it has to do with the KeepAlive and KeepAliveTimeout of Apache2 ... connecting directly against Gemstone gives a longer life ...

More testing needed

Am Freitag, 2. Oktober 2015 20:41:39 UTC+2 schrieb Marten Feldtmann:

No idea :-(

I looked down up to SciBlockingDispatcher>>callSendWith:with:with:with and printed all needed stuff and - NO error. VASmalltalk believes, that is has sent the stuff - but Apache2 does not log any requests.

If you set the KeepAlive option of Apache2 to off you get no more problems. But of course this is not a solution. So one should check the return values of HTTP request and if they are empty one should strongly think about shutingDown the socket and startUp a new socket connection and retry the request.