JDK-6495300 : JRE Thread Priority Mapping In Red Hat Linux
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0u7
  • Priority: P2
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux_2.4
  • CPU: sparc
  • Submitted: 2006-11-18
  • Updated: 2010-08-19
  • Resolved: 2006-11-29
Related Reports
Relates :  
Description
Problem Symptom : 	JRE Thread Priority Mapping In Red Hat Linux

Problem Description :

Nortel recently moved application from Solaris to Red Hat Linux and to surprise determined that the JVM thread priorties were all being mapped to the same 
operating system thread/process (in linux case) priority in Red Hat.

They really require the ability to prioritize their threads as some items such as heartbeats are more critical than other work.  
They would like an update on how and when this is being addressed in the 1.5+ JRE. 

They found this reference, which is only mildly useful as their application cannot run as root. 
Ref :  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4813310


Additional Information :
    1) Was the same application working fine with Solaris earlier ?
    [Nortel]  Yes. 
    2) Please let us know the details of the Linux o/s version being used.
    [Nortel]   Red Hat AS 4.0 
    3) Please let us know the complete jdk version which is being used.
    [Nortel]  1.5.0_07 
    4) We would like to have the complete details of what you are trying to implement within the application.
        And please let us know about various options which is being tried already.
    [Nortel]   This is a SIP call server.  Our I/O threads run at a higher priority than our other threads for reading off of UDP sockets and for heartbeats.  This insures we get messages into the applicaiton before the operating system discards them due to UDP buffer overflow and  in other cases fail to send heartbeats.  This works fine on Solaris when the server is pushed to high CPU occupancies... it does not on Linux.  Given the equal thread priority on Linux, we are not suprised by this behavior.
    5) And also, it would be nice to have a test case which reproduces the problem.
    [Nortel]   Unfortunately, one is not available.  This is a 4M LOC application that is not working. 


Workaround Suggested :

To try mapping the required thread level under consideration to the higher o/s level priority
Just for example, like below jvm option format settings :

-XX:JavaPriority1_To_OSPriority=XXX
-XX:JavaPriority2_To_OSPriority=YYY
    .....
-XX:JavaPriority10_To_OSPriority=ZZZ    where XXX, YYY and ZZZ are the o/s level thread priorities to be mapped into.


Attachments :

1)  File Name : netstat.zip 
      This attached file is a netstat that shows network info before calls, while calls are active and after the spike and failure. 
      You can see the delta in incoming packets discarded and udp packet receive errors.
 
2)  File name : ThreadPriorityMappingLogs.txt
     This file contains the logs after Nortel tried the above workaround, which is, Java thread priority mapping with Linux.
      And it has not produced convincing results for Nortel.

Comments
EVALUATION The lack of meaningful thread priorities is a platform restriction specific to linux. I'm sympathetic to Nortel's issue but the JVM can't provide meaningful thread priorities if the underlying platform doesn't provide sufficent support.
29-11-2006

WORK AROUND Workaround as suggested : To try mapping the required thread level under consideration to the higher o/s level priority Just for example, like below jvm option format settings : -XX:JavaPriority1_To_OSPriority=XXX -XX:JavaPriority2_To_OSPriority=YYY ..... -XX:JavaPriority10_To_OSPriority=ZZZ where XXX, YYY and ZZZ are the o/s level thread priorities to be mapped into. But it did not help. Logs are attached from the result of trying the workaround.
18-11-2006