[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] [Created] (AMQCPP-498) Client doesn't work on Linux Red Hat 6.4 systems, fails when setting t
From:       "John Rocha (JIRA)" <jira () apache ! org>
Date:       2013-06-28 23:28:19
Message-ID: JIRA.12655441.1372461985453.186783.1372462099961 () arcas
[Download RAW message or body]

John Rocha created AMQCPP-498:
---------------------------------

             Summary: 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
         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


[prev in list] [next in list] [prev in thread] [next in thread]