On Sat, 2008-03-08 at 10:31 +0800, xuhongbo wrote:
> Hi, Oleg:
> While using synapse-http-transport, I find out that there are two place
> of code will catched the exception:
> 1) SessionRequestCallback
> 2) ClientHandler( it implements NHttpClientHandler)
> But some exception SessionRequestCallback will catched, for example(
> Connection Refuse), while some others will be catched by ClientHandler for
> example: IO-Exception (after socket connected, while sending or receiving
> data)
>
> As synapse-http-transport original code process the SessionRequestCallback
> exception correctely. but not correctly process ClientHandler yet. So cannot
> immediately notify the client some-thing wrong with net-work.
>
> And in the patch for synapse-http-transport, I add code in the
> ClientHandler's callback (exception, closed, timeout, responseReceived...) to
> check if the request completed, or set the request to complete status(
> "complete" means received response from server).
>
> the code looks like :
> void exception(final NHttpClientConnection conn, final IOException e)
> {
> checkAxisRequestComplete(...);//check if completed, if not send a
> failure message-context back to synapse client
> }
> ....other callback
>
> void responseReceived(..)
> {
> //set Request to complete status ;
> }
>
> The request status check code repeated too much.
> So I think if http-core-nio provided one callback to detect and report
> http-request's status will be better.
>
> maybe SessionRequestCallback will be a better choice for this, but I am not
> very sure if SessionRequestCallback's design purpose (in http-core-nio)
> conflict with this;
>
> xuhongbo
>
Xuhongbo,
(1) Status of what request are you checking? Client to synapse? Synapse
to target server? Do not forget Synapse is a proxy, whereas HttpCore is
meant to be a generic transport library. It is not meant to provide
functions applicable to HTTP proxies only.
(2) NHttpClientConnection handles requests and responses completely
asynchronously. It can receive several pipelined requests before sending
out the first response. So, for instance, if an I/O exception occurs
while sending out a response, there is no point passing the status of
the _current_ request because there is no guarantee this request
corresponds to the failed response. This decision can be made at the
protocol handler level only.
(3) You can use the state of the encoder / decoder passed in the
NHttpClientHandler#outputReady() / NHttpServiceHandler#inputReady()
events to determine whether a request has been fully sent / received.
Hope this helps somewhat
Oleg
>
>
> ----- Original Message -----
> From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Saturday, March 08, 2008 3:49 AM
> Subject: Re: http-transport-bug fixed
>
>
> >
> > On Fri, 2008-03-07 at 18:24 +0800, XuHongBo wrote:
> >> Hi:
> >> I have just post a patch for 2 http-transport-bugs founded. but the
> >> patch code style is just work outside the http-core-nio to fixe problem.
> >>
> >> Oh.... some of the fixing code I think , should be the responsibility of
> >> http-core-nio library, so the fixed code will look like more structurable.
> >>
> >> Is there anyone who are familiar with http-core-nio give some advise about
> >> if we should waiting for http-core-nio library to be corrected to catch
> >> all all network failed in sessionCallback ( now only some exception
> >> catched by sessionCallback)?
> >>
> >
> > Hi Xuhongbo
> >
> > I guess I qualify as someone familiar. I am not sure I fully understand
> > the problem. Could you please give me a little more details as to what
> > kind of exceptions you think should be handled by HttpCore
> > automatically?
> >
> > Oleg
> >
> >> Or just like the patch code, work outside http-core-nio library?
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]