You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2010/05/26 01:35:31 UTC
[jira] Created: (TS-375) Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS
as a configurable option?
Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option?
------------------------------------------------------------------
Key: TS-375
URL: https://issues.apache.org/jira/browse/TS-375
Project: Traffic Server
Issue Type: New Feature
Reporter: Leif Hedstrom
Priority: Minor
Would it make sense to expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option? It would allow a very skilled user to tweak the lock rescheduling to fit her application, HW and load patterns "optimally". This would be a "stop-gap" solution for some situations, until we can reduce / eliminate some of the rescheduling that happens (and it would be very "application" specific).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-375) Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS
as a configurable option?
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-375:
-----------------------------
Component/s: InkAPI
> Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option?
> ------------------------------------------------------------------
>
> Key: TS-375
> URL: https://issues.apache.org/jira/browse/TS-375
> Project: Traffic Server
> Issue Type: New Feature
> Components: InkAPI
> Reporter: Leif Hedstrom
> Priority: Minor
> Fix For: 2.3.0
>
>
> Would it make sense to expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option? It would allow a very skilled user to tweak the lock rescheduling to fit her application, HW and load patterns "optimally". This would be a "stop-gap" solution for some situations, until we can reduce / eliminate some of the rescheduling that happens (and it would be very "application" specific).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-375) Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS
as a configurable option?
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-375:
-----------------------------
Fix Version/s: 2.3.0
> Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option?
> ------------------------------------------------------------------
>
> Key: TS-375
> URL: https://issues.apache.org/jira/browse/TS-375
> Project: Traffic Server
> Issue Type: New Feature
> Reporter: Leif Hedstrom
> Priority: Minor
> Fix For: 2.3.0
>
>
> Would it make sense to expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option? It would allow a very skilled user to tweak the lock rescheduling to fit her application, HW and load patterns "optimally". This would be a "stop-gap" solution for some situations, until we can reduce / eliminate some of the rescheduling that happens (and it would be very "application" specific).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.