JDK-8015375 : Edits to text components hang for clipboard access
  • Type: Bug
  • Component: client-libs
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2013-05-24
  • Updated: 2013-12-17
  • Resolved: 2013-06-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u40Fixed 8 b94Fixed
Related Reports
Relates :  
Steps to reproduce:
1. Install Oracle VM VirtualBox to your Windows PC
2. Create and set-up new Linux virtual machine, (e.g. Ubuntu, OEL, etc.) using VirtualBox
3. Install Java to your Linux virtual machine, (e.g. jdk7u09)
4. Install VNC to your Linux virtual machine
5. Start VNC server on your Linux virtual machine
6. Go to Windows and install VNC client, (ultra VNC, real VNC, etc.)
7. Login from Windows to you Linux virtual machine using VNC
8. Run ClipboardHanger test
9. Insert a lot of text into the text area that appears (I copy and paste the source code)
10. Select a few lines of code
11. Press control+enter

This triggers a number of inserts into the document under a write lock. Notice it takes a long time to return, but eventually does. 
The delay is caused by the secondary loop functionality located at the XlibWrapper.c file. The function XNextSecondaryLoopEvent() tests whether PropertyNotify or SelectionNotify event is in the queue or not. If there is the event in the queue, the function returns it; otherwise the function waits for 250 msecs and then checks the event queue again. It repeats this sequence until the event is received. When a local X server is used the function XNextSecondaryLoopEvent() obtains the event during the first iteration of the secondary loop, since it takes a very short time (less than 1 msecs) for the local X server to deliver the events to the queue. However, for a remote X server it takes about 2-10 msecs to deliver the events to the queue, so the XNextSecondaryLoopEvent() has to wait for 250 msecs before it obtains the events. Suggested fix: the function XNextSecondaryLoopEvent() should use a progressive time out value instead of hardcoded 250 msces during secondary loop execution, (i.e. it has to calculate the time out value based on the number of loops iteration).