thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "zengji (Jira)" <j...@apache.org>
Subject [jira] [Updated] (THRIFT-5230) Fix connection leak and CancelledKeyException when handling Epoll bug
Date Sun, 14 Jun 2020 01:07:00 GMT

     [ https://issues.apache.org/jira/browse/THRIFT-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

zengji updated THRIFT-5230:
---------------------------
    Description: 
1. When Epoll bug occurs, the TThreadedSelectorServer.rebuildSelector rebuilds only the channel
has events, the idle connection was ignored and caused connection leak

 
{code:java}
for (SelectionKey key : oldSelector.selectedKeys()) {
  if (!key.isValid() && key.readyOps() == 0)
    continue;
  SelectableChannel channel = key.channel();
  Object attachment = key.attachment();

  try {
    if (attachment == null) {
      channel.register(newSelector, key.readyOps());
    } else {
      channel.register(newSelector, key.readyOps(), attachment);
    }
  } catch (ClosedChannelException e) {
    LOGGER.error("Register new selector key error.", e);
  }
}

selector = newSelector;
try {
  oldSelector.close();
} catch (IOException e) {
  LOGGER.error("Close old selector error.", e);
}

{code}
2. When re-register the channel to new selector, the interested ops should same as before,
not only the readyOps

 

3. In the same code block, the channel will be registered to a new selector and the previous
selector will be closed, but the FrameBuffer is still holding the previous selector causing
the FrameBuffer in a wrong state. When the FrameBuffer is trying to processing the channel,
it may occur a CancelledKeyException.This issue (CancelledKeyException) has been reported
before:https://issues.apache.org/jira/browse/THRIFT-4847

  was:
1. When Epoll bug occurs, the TThreadedSelectorServer.rebuildSelector rebuilds only the channel
has events, the idle connection was ignored and caused connection leak

 
{code:java}
for (SelectionKey key : oldSelector.selectedKeys()) {
  if (!key.isValid() && key.readyOps() == 0)
    continue;
  SelectableChannel channel = key.channel();
  Object attachment = key.attachment();

  try {
    if (attachment == null) {
      channel.register(newSelector, key.readyOps());
    } else {
      channel.register(newSelector, key.readyOps(), attachment);
    }
  } catch (ClosedChannelException e) {
    LOGGER.error("Register new selector key error.", e);
  }
}

selector = newSelector;
try {
  oldSelector.close();
} catch (IOException e) {
  LOGGER.error("Close old selector error.", e);
}

{code}
2. When re-register the channel to new selector, the interested ops should same as before,
not only the readyOps

 

3. In the same code block, the channel will be registered to a new selector and the previous
selector will be closed, but the FrameBuffer is still holding the previous selector causing
the FrameBuffer in a wrong state. When the FrameBuffer is trying to processing the channel,
it may occur a CancelledKeyException.

This issue has been reported before:

https://issues.apache.org/jira/browse/THRIFT-4847


> Fix connection leak and CancelledKeyException when handling Epoll bug
> ---------------------------------------------------------------------
>
>                 Key: THRIFT-5230
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5230
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>    Affects Versions: 0.13.0
>         Environment: java version "1.8.0_161"
>            Reporter: zengji
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 1. When Epoll bug occurs, the TThreadedSelectorServer.rebuildSelector rebuilds only the
channel has events, the idle connection was ignored and caused connection leak
>  
> {code:java}
> for (SelectionKey key : oldSelector.selectedKeys()) {
>   if (!key.isValid() && key.readyOps() == 0)
>     continue;
>   SelectableChannel channel = key.channel();
>   Object attachment = key.attachment();
>   try {
>     if (attachment == null) {
>       channel.register(newSelector, key.readyOps());
>     } else {
>       channel.register(newSelector, key.readyOps(), attachment);
>     }
>   } catch (ClosedChannelException e) {
>     LOGGER.error("Register new selector key error.", e);
>   }
> }
> selector = newSelector;
> try {
>   oldSelector.close();
> } catch (IOException e) {
>   LOGGER.error("Close old selector error.", e);
> }
> {code}
> 2. When re-register the channel to new selector, the interested ops should same as before,
not only the readyOps
>  
> 3. In the same code block, the channel will be registered to a new selector and the previous
selector will be closed, but the FrameBuffer is still holding the previous selector causing
the FrameBuffer in a wrong state. When the FrameBuffer is trying to processing the channel,
it may occur a CancelledKeyException.This issue (CancelledKeyException) has been reported
before:https://issues.apache.org/jira/browse/THRIFT-4847



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message