activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (AMQCPP-498) Client doesn't work on Linux Red Hat 6.4 systems, fails when setting thread priority
Date Mon, 01 Jul 2013 18:08:20 GMT

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

Timothy Bish resolved AMQCPP-498.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 3.8.0
                   3.7.1

Fixed on trunk and 3.7.x branch.
                
> Client doesn't work on Linux Red Hat 6.4 systems, fails when setting thread priority
> ------------------------------------------------------------------------------------
>
>                 Key: AMQCPP-498
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-498
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Decaf
>    Affects Versions: 3.5.0
>         Environment: Linux Red Hat 6.4
>            Reporter: John Rocha
>            Assignee: Timothy Bish
>            Priority: Critical
>              Labels: decaf, priority, pthreads, scheduling, thread
>             Fix For: 3.7.1, 3.8.0
>
>         Attachments: patch.TBD
>
>
> Client doesn't work on Linux Red Hat 6.4 systems. It fails throwing the exception {panel}Failed
to set new Therad priority to value: 18{panel}
> This is coming from the file
> {{{color:brown}src/main/decaf/internal/util/concurrent/unix/PlatformThread.cpp{color}}}
> when it's creating a new thread.
> We encountered this problem when we started running our code on a new operating system.
It worked fine on Redhat 5.8 and SuSE SLES10, but then it started failing on Redhat 6.4.
> I did some digging and found a defect logged against the _+pthread+_ library at: http://sourceware.org/bugzilla/show_bug.cgi?id=10828.
> {panel}(This problem was found by analyzing a failure of LSB distribution compliance
test, lsb-runtime, v. 4.0.2.)
> A relatively new change in $GITROOT/glibc/nptl/pthread_attr_setschedparam.c (2009-04-23
according to git) adds a check to pthread_attr_setschedparam() call whether the priority being
set is compatible with the scheduling policy already set in the structure; if the priority
is not in the prescribed range, it fails, generating the EINVAL error.
> This check, although well intended, has a side effect that can break existing code (at
least the LSB tests): it makes the process of initializing a pthread_attr structure order-dependent
on Linux.
> As Linux does not use the numeric priority for SCHED_OTHER, which is the default, and
sched_get_priority_min() and sched_priority_max() return 0. Therefore:
> If a programmer calls pthread_attr_init(), then pthread_attr_setschedpolicy() to set
SCHED_RR or SCHED_FIFO, and then pthread_attr_setschedparam(), it works. But if the other
way around (priority first, then scheduling policy), it fails for "no apparent reason".{panel}
> I did some debugging in the code and found that {{unix/PlatformThread.cpp}}'s method
{{createNewThread()}} sets the scheduling priority but doesn't set the scheduling policy.
And the default value for the scheduling policy is SCHED_OTHER(0) which only supports a priority
value of 0.
> I have a proposed patch which:
> # validates the return values of all pthread calls and
> # only sets the priority iff the policy is sset to SCHED_FIFO or SCHED_RR
> Granted, we never set the policy so one could argue that we should just remove setting
of the priority. However, I suspect that the true desire is to inherit the current threads
scheduling value and set the priority based on that. So I anticipate tha future changes may
actually set the policy. I didn't do this though.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message