Uploaded image for project: 'ActiveMQ C++ Client'
  1. ActiveMQ C++ Client
  2. AMQCPP-498

Client doesn't work on Linux Red Hat 6.4 systems, fails when setting thread priority



    • Patch Available


      Client doesn't work on Linux Red Hat 6.4 systems. It fails throwing the exception

      Failed to set new Therad priority to value: 18

      This is coming from the file
      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.

      (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".

      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:

      1. validates the return values of all pthread calls and
      2. 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.


        1. patch.TBD
          3 kB
          John Rocha



            tabish Timothy A. Bish
            jrr John Rocha
            0 Vote for this issue
            2 Start watching this issue