I guess I get what you mean. Do you know if the same kind of explanation
applies to these ?
Apr 20, 2015 12:11:05 AM org.apache.coyote.AbstractProcessor setErrorState
INFO: An error occurred in processing while on a non-container thread. The
connection will be closed immediately
java.nio.channels.AsynchronousCloseException
at
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:205)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:496)
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:128)
at
org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101)
at
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
at
org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
at
org.apache.coyote.http11.InternalNioOutputBuffer.flushBuffer(InternalNioOutputBuffer.java:242)
at
org.apache.coyote.http11.InternalNioOutputBuffer.endRequest(InternalNioOutputBuffer.java:121)
at
org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:762)
at org.apache.coyote.Response.action(Response.java:174)
at org.apache.coyote.Response.finish(Response.java:274)
at
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:319)
at
org.apache.catalina.connector.CoyoteWriter.close(CoyoteWriter.java:112)
at
networkComm.commands.HttpCommand.sendResponse(HttpCommand.java:224)
at
com.stickyadstv.adex.AuctioneerResponseWriter.respondToClient(AuctioneerResponseWriter.java:322)
at
com.stickyadstv.adex.BidSerializationListener.checkSerializationIsComplete(BidSerializationListener.java:70)
at
com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:53)
at
com.stickyadstv.adex.bidder.marketplace.MarketPlaceBidSerializationWriter.respondToClient(MarketPlaceBidSerializationWriter.java:92)
at
com.stickyadstv.adex.BidSerializationListener.checkSerializationIsComplete(BidSerializationListener.java:70)
at
com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:53)
at
com.stickyadstv.adex.BidSerializationListener.completed(BidSerializationListener.java:24)
at
org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115)
at
com.stickyadstv.adex.bidder.internal.InternalBid.serializeAsVAST(InternalBid.java:56)
at
com.stickyadstv.adex.bidder.marketplace.MarketPlaceBid.serializeAsVAST(MarketPlaceBid.java:151)
at
com.stickyadstv.adex.AuctioneerResponseWriter.completed(AuctioneerResponseWriter.java:120)
at com.stickyadstv.adex.Auctioneer.bangTheGavel(Auctioneer.java:521)
at com.stickyadstv.adex.Auctioneer.close(Auctioneer.java:236)
at
com.stickyadstv.adex.Auctioneer.checkCompletion(Auctioneer.java:195)
at
com.stickyadstv.adex.Auctioneer.registerBuyerPlatformResponses(Auctioneer.java:178)
at
com.stickyadstv.adex.bidder.openrtb.OpenRTBBuyerRequest.flagAllAsNotParticipating(OpenRTBBuyerRequest.java:428)
at
com.stickyadstv.adex.bidder.openrtb.OpenRTBBuyerRequest.setBidResponse(OpenRTBBuyerRequest.java:139)
at
com.stickyadstv.adex.bidder.openrtb.OpenRTBBidRequestAsyncListener.completed(OpenRTBBidRequestAsyncListener.java:27)
at
com.stickyadstv.adex.bidder.openrtb.OpenRTBBidRequestAsyncListener.completed(OpenRTBBidRequestAsyncListener.java:12)
at
org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:115)
at
org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(DefaultClientExchangeHandlerImpl.java:173)
at
org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAsyncRequestExecutor.java:355)
at
org.apache.http.nio.protocol.HttpAsyncRequestExecutor.responseReceived(HttpAsyncRequestExecutor.java:230)
at
org.apache.http.impl.nio.client.LoggingAsyncRequestExecutor.responseReceived(LoggingAsyncRequestExecutor.java:112)
at
org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:254)
at
org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:73)
at
org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:37)
at
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:113)
at
org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:159)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:338)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:316)
at
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:277)
at
org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:105)
at
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:584)
at java.lang.Thread.run(Thread.java:745)
Also I'm glad to get a lot of feed back that help confirming my opinions or
give me new path to follow. Unfortunetly so far nothing seems to explain
why the peaks occur a lot in the last release of tomcat but only
occassionally in the previous one we used.
Thomas
2015-04-21 16:56 GMT+02:00 André Warnier <a...@ice-sa.com>:
> Thomas Boniface wrote:
>
>> The file descriptor peak show up in our monitoring application. We have
>> some charts showing the number of file descriptors owned by the tomcat
>> process (ls /proc/$(pgrep -u tomcat7)/fd/ | wc -l).
>>
>> The calatalina.out log shows errors, the most frequent being a
>> java.io.IOException: Broken pipe.
>>
>> [..]
>
> A "broken pipe", from the server perspective while sending a response to
> the client, is a rather usual thing. It usually means that the (human)
> client got tired of waiting for a response, and clicked somewhere else in
> the browser (maybe a "cancel" button; maybe he closed the window; etc..).
> The browser would then immediately close the connection with the server,
> and when the server eventually tries to write anything else to that
> connection, the "broken pipe" exception would be the result.
> With the numbers you quoted previously regarding the number of
> simultaneous client sessions, it doesn't look extraordinary that this would
> happen regularly.
> Maybe the thing to investigate here is whether your server is really so
> slow in answering clients, that a significant portion of them do get tired
> of waiting and get an irresistible urge to click elsewhere..
>
> Apart from the human client, browsers themselves have a built-in timeout
> for waiting for a server response, and will themselves give up after a
> while. That is on the order of 4-5 minutes after sending the request and
> not receiving anything from the server in response.
> Some applications are such that they can sometimes take more than that to
> be able to send a response. In such cases, to avoid the browser timeout
> (and connection close), there are "tricks" to use, to send intermediate
> kind of "wait message" to the browser, so that it does not hang up.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
