[
https://issues.apache.org/jira/browse/THRIFT-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chaoyu Tang updated THRIFT-2046:
--------------------------------
Attachment: THRIFT-2046_2.patch
[~tlipcon] Thanks for the review and comments. I have tried to address what you
raised:
1) have the unit associated with requestTimeout. I did it just like the code
has done for the stopTimeout. also I changed the existing constant one-second
sleep to a binary exponential back off algorithm to space out the retry.
3) use client.close() instead
As for 2): currently the server is using SynchronousQueue which works best to
the direct handoff queuing strategy. If BlockQueue implementation is used, the
server queuing behavior might change a little. For example, If corePoolSize or
more threads are running, the Executor always prefers queuing a request rather
than adding a new thread (see ThreadPoolExecutor.java). I think it might not be
ideal to a server, right?
> The worktask can be timed out in TThreadPoolServer (Java) when the max#
> thrift thread is reached
> ------------------------------------------------------------------------------------------------
>
> Key: THRIFT-2046
> URL: https://issues.apache.org/jira/browse/THRIFT-2046
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
> Affects Versions: 0.9
> Reporter: Chaoyu Tang
> Attachments: THRIFT-2046.patch, THRIFT-2046_1.patch,
> THRIFT-2046_2.patch
>
>
> Once the max# of thrift threads is reached, a new task (workprocess) is
> attempted to be executed in an infinite loop, then the client may hang.
> An improvement is to introduce a task timeout. after a certain time, if the
> task is still not got queued to be executed. It will be invalidated.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
