I came across the following discussion, which has a somewhat similar stack trace:
http://groups.google.com/group/jets3t-users/browse_thread/thread/7fc0609b67aca645?fwc=1 Is it possible that javax.swing.filechooser.FileSystemView is designed only to be called from the event dispatch thread? That would be consistent with its being "JFileChooser's gateway to the file system" ( http://java.sun.com/javase/6/docs/api/javax/swing/filechooser/FileSystemView.html). It would also be consistent with the observation that the bug only shows up some of the time. If so, then com.lightcrafts.platform.windows.WindowsPlatform.getDisplayNameOf could get around this limitation, as described in the discussion above, by using SwingUtilities.invokeAndWait() when calling methods of javax.swing.filechooser.FileSystemView from a thread other than the event dispatch thread. (Use SwingUtilties.isEventDispatchThread() to determine this.) --tim On Fri, Jul 11, 2008 at 8:32 AM, Kevin Conaway <[EMAIL PROTECTED]> wrote: > Why are there so many threads blocked on: > > Thread-14" prio=6 tid=0x2eb16800 nid=0x11c4 waiting on condition >> [0x30c2f000..0x30c2fd94] >> java.lang.Thread.State: WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x2a9d7808> (a >> java.util.concurrent.FutureTask$Sync) >> at java.util.concurrent.locks.LockSupport.park(Unknown Source) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown >> Source) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown >> >> Source) >> at >> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown >> >> Source) >> at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) >> at java.util.concurrent.FutureTask.get(Unknown Source) >> at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown >> Source) >> at sun.awt.shell.Win32ShellFolder2.<init>(Unknown Source) >> at sun.awt.shell.Win32ShellFolderManager2.getDrives(Unknown Source) >> at sun.awt.shell.Win32ShellFolderManager2.isFileSystemRoot(Unknown >> Source) >> at sun.awt.shell.ShellFolder.isFileSystemRoot(Unknown Source) >> at javax.swing.filechooser.FileSystemView.isFileSystemRoot(Unknown >> Source) >> at javax.swing.filechooser.FileSystemView.getSystemDisplayName(Unknown >> Source) > > ..... >> > > That seems a little odd to me. Are there missing network drives or > anything similar which would cause the filechooser to hang? > > How many threads do you have simple configured to use? What version of > simple are you using? > > > On Fri, Jul 11, 2008 at 3:33 AM, Jerome Louvel <[EMAIL PROTECTED]> > wrote: > >> Hi Kevin, >> >> Paul has entered a bug report with the thread dump: >> >> "Hanging on ServerSocket.accept()" >> http://restlet.tigris.org/issues/show_bug.cgi?id=528 >> >> I have no clue for now, any help is welcome. >> >> Best regards, >> Jerome >> >> >> ------------------------------ >> *De :* Kevin Conaway [mailto:[EMAIL PROTECTED] >> *Envoyé :* jeudi 10 juillet 2008 14:50 >> *À :* [email protected] >> >> *Objet :* Re: Hanging on ServerSocket.accept() >> >> Please attach a thread dump to your bug report. >> >> On Thu, Jul 10, 2008 at 4:27 AM, Jerome Louvel <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Hi Paul, >>> >>> Thanks for the details, this needs to be looked at more closely. Could >>> you >>> enter a bug report? >>> http://www.restlet.org/community/issues >>> >>> Best regards, >>> Jerome >>> >>> >>> -----Message d'origine----- >>> De : Paul J. Lucas [mailto:[EMAIL PROTECTED] >>> Envoye : lundi 7 juillet 2008 19:40 >>> A : [email protected] >>> Objet : Re: Hanging on ServerSocket.accept() >>> >>> On Jul 4, 2008, at 3:57 AM, Jerome Louvel wrote: >>> >>> > What do you mean by launching 1/10 times? >>> >>> I mean that the problem only manifests immediately after launch (if it >>> manifests at all). The problem never manifests if the software has >>> been running OK for a while (meaning it has been servicing requests). >>> >>> > Do you stop and restart the application? >>> >>> Yes. >>> >>> > Do you do this using Component#start() and stop() methods ... >>> >>> Yes. >>> >>> > and differently? >>> >>> I don't know what you mean by that. >>> >>> > It is important to cleanly shutdown your server connector in order >>> > to quickly release the open sockets. >>> >>> It's not that the server can not *bind* to the socket -- it does. >>> (The problem I assume you are referring to is the SO_LINGER option on >>> the socket.) >>> >>> It binds, listens, and does an accept -- and it hangs on the accept. >>> >>> > Did you looked at the list of open TCP/IP sockets under Windows? You >>> > can try >>> > 'netstat -n' for example. >>> >>> I know the socket is open and accepting because I can telnet to the >>> port. Both the telnet client and server hang. >>> >>> - Paul >>> >>> >> >
