Hello Oleg, I thought I would just explain my understanding/concern related to the log:
Success Scenario: 1. Client sends the Request Header 2. Client sends the Request Body 3. Server sends 404 4. Server closes the connection 5. Client Acknowledges Failure Scenario: 1. Client sends the Request Header. 2. Server sends 404 3. Server closes the connection. 4. Client Acknowledges 5. Client sends the Request Body. In the case of failure, I have two questions: - Why does the acknowledgement to 404 message is not getting passed to the Application Layer? - If my understanding is incorrect about the above observation, then why would the client still send the request body after acknowledging? Feel free to correct me at any point. Thanks for your help. Poonam -----Original Message----- From: Oleg Kalnichevski [mailto:ol...@apache.org] Sent: Tuesday, April 30, 2013 6:32 AM To: HttpClient User Discussion Subject: Re: Apache HTTP Client fails to return 404 for a non-existing file. On Mon, 2013-04-29 at 15:00 +0000, Poonam Chawla wrote: > Hello, > > I am working with Apache's HTTP async client and have encountered a possible > bug (race condition). > > PROBLEM: > While accessing a nonexistent file on the server, I would ALWAYS expect to > receive a "404 : component not found" error message. > However, the behavior is sporadic. Sometimes I receive the correct message, > whereas, on the other occasions it throw the following exception: > > org.apache.http.impl.nio.client.LoggingAsyncRequestExecutor exception > SEVERE: http-outgoing-1 [ACTIVE] HTTP protocol exception: An > established connection was aborted by the software in your host > machine > java.io.IOException: An established connection was aborted by the > software in your host machine at > sun.nio.ch.SocketDispatcher.read0(Native Method) at > sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225) > at sun.nio.ch.IOUtil.read(IOUtil.java:198) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359) > at > org.apache.http.impl.nio.reactor.SessionInputBufferImpl.fill(SessionIn > putBufferImpl.java:97) at > org.apache.http.impl.nio.codecs.AbstractMessageParser.fillBuffer(Abstr > actMessageParser.java:115) at > org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(Def > aultNHttpClientConnection.java:167) > at > org.apache.http.impl.nio.DefaultHttpClientIODispatch.onInputReady(Defa > ultHttpClientIODispatch.java:125) at > org.apache.http.impl.nio.DefaultHttpClientIODispatch.onInputReady(Defa > ultHttpClientIODispatch.java:50) at > org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(Abstrac > tIODispatch.java:112) at > org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor. > java:160) at > org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(Abstra > ctIOReactor.java:342) at > org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(Abstr > actIOReactor.java:320) at > org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOR > eactor.java:280) at > org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.j > ava:106) at > org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.r > un(AbstractMultiworkerIOReactor.java:604) > at java.lang.Thread.run(Thread.java:722) > > java.io.IOException: An established connection was aborted by the > software in your host machine > > INVESTIGATION: > I downloaded the source code and tried to investigate it myself. > Interestingly, I found that the "IOReactorStatus" is set to > "SHUTDOWN_REQUEST" only after the exception has already been thrown. > I am not sure if this is the root cause or not, but I would highly appreciate > if somebody could please confirm if it's a known issue and if there exists a > solution. > > Thanks, > Poonam Poonam HTTP 404 response is in no way no different or special as far as HTTP exchange handling is concerned. It is just a 4xx message potentially enclosing a content entity. That is it. If you are seeing this kind of behavior for non-existent resources but not for normal resources (status 200) I would strongly suspect a server side issue. A wire / content log produced by HttpAsyncClient or a Wireshark packet dump might help prove or disprove that. http://hc.apache.org/httpcomponents-client-ga/logging.html Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
