Sebastian, It would be helpful to know which version of Pharo and Zinc HTTP Components you are using. That being said, there is not much special about #beOneShot. ZnClient always does HTTP 1.1 which means it defaults to keeping connections open and handling multiple request/response cycles over it, each side should be ready to handle unexpected closing. What #beOneShot does, is setting 'Connection: close' in the request, which tells the server that it does _not_ intend to send more than one request and will not read more than one response. This is standard behavior. I understand that you cannot provide a reproduceable situation, but I need more information if you expect me to help you. Maybe you can send a stacktrace with sensitive information filtered out. What you can also do is inspect both the request and response instance variable of the ZnClient object right after the failure. Since you only get it with one service, it will be related to that service. I have no other reports of problems in this area (and ZnClient is used daily in all Pharo 1.3, 1.4 and 2.0 images), but maybe you hit some border case that can help improve the code. Sven On 30 Aug 2012, at 16:53, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hi there,
I've started using Zinc in more projects and it's doing well.
Except for one thing :)
Using the http client, I've found exceptions happening when receiving the answer after the request.
I remember one related to someone sending #contents and failing due to entity being nil instead of the expected something stream related (see ZnClient>>contents).
I also found that not using #beOneShot helps.
If I make #beOneShot a no-op by commenting "self optionAt: #oneShot put: true" everything works as expected.
That makes #beOneShot suspicious about making the client to close the connection before getting the contents of the data answered in the stream. It seems to be closing the connection without reading the answer the server sent.
I don't know of more cases but this of course *had* to happen when using Merchant* to talk to my gateway to process credit card payments so you can have an idea how frustrating this is.
With the workaround things are okay so far but I'm a little worried about this bug because it seems that beOneShot is the default for everything http client in Pharo and it is going to be needed a lot.
Let me know how I can be of further help to get this fixed
sebastian
o/
*Merchant is available in squeak source and yeah, I know, I should move it to ss3 but maybe I'm waiting for smalltalkhub
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill