[jira] [Updated] (TS-4612) Proposal: InactivityCop Optimize

2016-10-07 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-4612:
--
Backport to Version: 7.0.0

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



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


[jira] [Updated] (TS-4612) Proposal: InactivityCop Optimize

2016-09-23 Thread Oknet Xu (JIRA)

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

Oknet Xu updated TS-4612:
-
Issue Type: Improvement  (was: Bug)

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



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


[jira] [Updated] (TS-4612) Proposal: InactivityCop Optimize

2016-06-29 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-4612:
--
Fix Version/s: sometime

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



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


[jira] [Updated] (TS-4612) Proposal: InactivityCop Optimize

2016-06-29 Thread Leif Hedstrom (JIRA)

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

Leif Hedstrom updated TS-4612:
--
Component/s: (was: Cop)
 Network
 Core

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



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


[jira] [Updated] (TS-4612) Proposal: InactivityCop Optimize

2016-06-29 Thread Oknet Xu (JIRA)

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

Oknet Xu updated TS-4612:
-
Description: 
By review the processing of InactivityCop::check_inactivity():

1. get all local vc from open_list
2. put them into cop_list
3. check every vc in cop_list if it is already timeouted
4. callback vc->handleEvent to close vc if it is timeout

InactivityCop and NetHandler share one mutex.
InactivityCop runs every second, NetHandler runs every 10ms, that means 
Nethandler runs 100 times until next InactivityCop runs.

if one vc has read/write in a Nethandler call, it is won't be timeout in the 
next InactivityCop run.

Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
the InactivityCop runs would get better performace.


  was:
NetHandler has a method: _close_vc , It is called by InactivityCop.

first, create a dummy Event in stack,
then call UnixNetVConnection::mainEvent by vc->handleEvent(EVENT_IMMEDIATE, 
);

the handleEvent is mainEvent here.

In the UnixNetVConnection::mainEvent code:

```
int
UnixNetVConnection::mainEvent(int event, Event *e)
{
  ink_assert(event == EVENT_IMMEDIATE || event == EVENT_INTERVAL);
  ink_assert(thread == this_ethread());

  MUTEX_TRY_LOCK(hlock, get_NetHandler(thread)->mutex, e->ethread);
  MUTEX_TRY_LOCK(rlock, read.vio.mutex ? read.vio.mutex : e->ethread->mutex, 
e->ethread);
  MUTEX_TRY_LOCK(wlock, write.vio.mutex ? write.vio.mutex : e->ethread->mutex, 
e->ethread);

  if (!hlock.is_locked() || !rlock.is_locked() || !wlock.is_locked() ||
  (read.vio.mutex && rlock.get_mutex() != read.vio.mutex.get()) ||
  (write.vio.mutex && wlock.get_mutex() != write.vio.mutex.get())) {
#ifdef INACTIVITY_TIMEOUT
if (e == active_timeout)
#endif
  e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
return EVENT_CONT;
  }
```

the dummy Event would be schedule_in into Event System by 
e->schedule_in(HRTIME_MSECONDS(net_retry_delay));

I think we should move the schedule_in into the INACTIVITY_TIMEOUT macro.

```
#ifdef INACTIVITY_TIMEOUT
if (e == active_timeout)
  e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
#endif
```

I'm try to allocate a Event instead dummy Event, but meet Event System callback 
on a deallocated UnixNetVConnection.

due to NetHandler called close_UnixNetVConnection before Event System callback 
the Event by schedule_in.

In NetHandler::_close_vc, depend the return value (EVENT_DONE or EVENT_CONT) 
from UnixNetVConnection::mainEvent, to do ++handle_event; or not.

```
if (vc->handleEvent(EVENT_IMMEDIATE, ) == EVENT_DONE)
  ++handle_event;
```

the 3 MUTEX_TRY_LOCK not always success on InactivityCop callback,
due to the mutex of ServerSessionVC may different from ClientSessionVC.

Only mutex of ServerSession is set to HttpSM when HttpSM pick up a Server 
Session from SessionPool. ServerSessionVC still keep the old mutex.


> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Reporter: Oknet Xu
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



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


[jira] [Updated] (TS-4612) Proposal: InactivityCop Optimize

2016-06-29 Thread Oknet Xu (JIRA)

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

Oknet Xu updated TS-4612:
-
Summary: Proposal: InactivityCop Optimize  (was: In 
UnixNetVConnection::mainEvent should not do e->schedule_in for dummy event 
callback )

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cop
>Reporter: Oknet Xu
>
> NetHandler has a method: _close_vc , It is called by InactivityCop.
> first, create a dummy Event in stack,
> then call UnixNetVConnection::mainEvent by vc->handleEvent(EVENT_IMMEDIATE, 
> );
> the handleEvent is mainEvent here.
> In the UnixNetVConnection::mainEvent code:
> ```
> int
> UnixNetVConnection::mainEvent(int event, Event *e)
> {
>   ink_assert(event == EVENT_IMMEDIATE || event == EVENT_INTERVAL);
>   ink_assert(thread == this_ethread());
>   MUTEX_TRY_LOCK(hlock, get_NetHandler(thread)->mutex, e->ethread);
>   MUTEX_TRY_LOCK(rlock, read.vio.mutex ? read.vio.mutex : e->ethread->mutex, 
> e->ethread);
>   MUTEX_TRY_LOCK(wlock, write.vio.mutex ? write.vio.mutex : 
> e->ethread->mutex, e->ethread);
>   if (!hlock.is_locked() || !rlock.is_locked() || !wlock.is_locked() ||
>   (read.vio.mutex && rlock.get_mutex() != read.vio.mutex.get()) ||
>   (write.vio.mutex && wlock.get_mutex() != write.vio.mutex.get())) {
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
> #endif
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> return EVENT_CONT;
>   }
> ```
> the dummy Event would be schedule_in into Event System by 
> e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> I think we should move the schedule_in into the INACTIVITY_TIMEOUT macro.
> ```
> #ifdef INACTIVITY_TIMEOUT
> if (e == active_timeout)
>   e->schedule_in(HRTIME_MSECONDS(net_retry_delay));
> #endif
> ```
> I'm try to allocate a Event instead dummy Event, but meet Event System 
> callback on a deallocated UnixNetVConnection.
> due to NetHandler called close_UnixNetVConnection before Event System 
> callback the Event by schedule_in.
> In NetHandler::_close_vc, depend the return value (EVENT_DONE or EVENT_CONT) 
> from UnixNetVConnection::mainEvent, to do ++handle_event; or not.
> ```
> if (vc->handleEvent(EVENT_IMMEDIATE, ) == EVENT_DONE)
>   ++handle_event;
> ```
> the 3 MUTEX_TRY_LOCK not always success on InactivityCop callback,
> due to the mutex of ServerSessionVC may different from ClientSessionVC.
> Only mutex of ServerSession is set to HttpSM when HttpSM pick up a Server 
> Session from SessionPool. ServerSessionVC still keep the old mutex.



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