yeah I understad the idea and sounds good. I'm sending you in private some screenshots of the debugger...
sebastian o/ On Aug 30, 2012, at 5:04 PM, Sven Van Caekenberghe wrote: > 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 <[email protected]> > 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 > > > >
