Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Fri, 4 Mar 2016 20:39:40 +0000 (UTC)
From: "Andrew Shore (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12947053.1457116803000.9037.1457123980729@Atlassian.JIRA>
In-Reply-To: <JIRA.12947053.1457116803000@Atlassian.JIRA>
References: <JIRA.12947053.1457116803000@Atlassian.JIRA>
 <JIRA.12947053.1457116803427@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1728) AWS SDK Java Request Timeout
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180506#comment-15180506 ] 

Andrew Shore commented on HTTPCLIENT-1728:
------------------------------------------

We are currently in the process of moving to 4.5 and off the deprecated classes. Is this a known issue? Is our implementation of request timeouts valid in the latest version of the client?

> AWS SDK Java Request Timeout
> ----------------------------
>
>                 Key: HTTPCLIENT-1728
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1728
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.4.1
>            Reporter: Andrew Shore
>            Priority: Minor
>
> This is a bit of an open ended question and not a bug in the Apache client but a bug in our code. To give a bit of background we've recently implemented a request timeout feature that works by launching a timer task that keeps a reference to the current running request and aborts it when it wakes up. This has been working well but we've recently gotten reports that it can put a connection in a bad state on the pool. We suspect this is due to using the request objects, which are explicitly documented as not thread safe, in a multi threaded fashion. We seem to be aborting the connection while or after it's being released to the pool which results in an IllegalStateException on the next request. We were wondering if there was a safer way to implement this feature that doesn't result in connections being put into a bad state.
> Here's the code that starts the timer.
> https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/http/AmazonHttpClient.java#L856-L879
> And here's the timer task implementation that aborts the request.
> https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/http/timers/request/HttpRequestAbortTaskImpl.java
> Stack trace of connection in bad state
> java.lang.IllegalStateException: Connection is not open
>         at org.apache.http.util.Asserts.check(Asserts.java:34)
>         at org.apache.http.impl.SocketHttpClientConnection.assertOpen(SocketHttpClientConnection.java:75)
>         at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseEntity(AbstractHttpClientConnection.java:293)
>         at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseEntity(ManagedClientConnectionImpl.java:192)
>         at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
>         at com.amazonaws.http.protocol.SdkHttpRequestExecutor.doReceiveResponse(SdkHttpRequestExecutor.java:82)
>         at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
>         at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682)
>         at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486)
>         at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
>         at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>         at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
>         at com.amazonaws.http.AmazonHttpClient.executeOneRequest(AmazonHttpClient.java:822)
>         at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:576)
>         at com.amazonaws.http.AmazonHttpClient.doExecute(AmazonHttpClient.java:362)
>         at com.amazonaws.http.AmazonHttpClient.executeWithTimer(AmazonHttpClient.java:328)
>         at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:307)
>         at com.amazonaws.services.kinesis.AmazonKinesisClient.invoke(AmazonKinesisClient.java:1753)
>         at com.amazonaws.services.kinesis.AmazonKinesisClient.getRecords(AmazonKinesisClient.java:783)
>         at com.amazonaws.services.catalog.search.kinesis.Shard.getStreamRecordsResult(Shard.java:180)
>         at com.amazonaws.services.catalog.search.kinesis.Shard.enqueueStreamRecords(Shard.java:157)
>         at com.amazonaws.services.catalog.search.kinesis.Shard.getRecordFromQueue(Shard.java:136)
>         at com.amazonaws.services.catalog.search.kinesis.Shard.popNextRecord(Shard.java:125)
>         at com.amazonaws.services.catalog.search.eventstream.ShardEventProcessor.processEvents(ShardEventProcessor.java:82)
>         at com.amazonaws.services.catalog.search.eventstream.ShardEventsTask.startProcessing(ShardEventsTask.java:60)
>         at com.amazonaws.services.catalog.search.eventstream.ShardEventsTask.call(ShardEventsTask.java:45)
>         at com.amazonaws.services.catalog.search.eventstream.ShardEventsTask.call(ShardEventsTask.java:8)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org