powered by Jive Software

Spark Makes Workstation Unresponsive

Hey guys, I have had 3 different users complain that when Spark is running, their workstation becomes virtually unresponsive. This problem goes away as soon as the user shuts down Spark.

I have not seen this behavior myself, nor have the other 250+ users using Spark and Wildfire in our organization.

Here are our specs:

Spark 1.1.1

Windows XP Pro SP2 + All hotfixes

All of our workstations are either Dell GX 260’‘s, 270’‘s or 280’‘s (P4 2.8GHz, 512MB, pretty beefey workstations) and they are all running the same workstation image. However, some users can and do have special software installed that is not part of the original workstation image. I’'m going to see if this may be the cause of the problem.

Here is what I know about the problem:

It only affects a very small number of users.

It seems to be profile based, meaning if the affected user logs on to another workstation the problem still occurs. However, if a user who is not affected logs onto that same workstation they will have no problem.

The affected users error.log file is empty (0 byte file) and there is no warning.log.

I am going to do some more troubleshooting to try and narrow this down and post my results here. I’'m going to start by giving the affected user a temporary fresh Windows profile and see if they are still affected.

Also, I found a few other threads related to this problem:




Hi Caleb,

First off, I would like to thank you for a great issue description Makes debugging a whole lot easier. So I’'m curious if the issues are occuring due to some of the native logic I use to determine idle time, etc. What I could do is create a “special” build that removes this logic and see if the problem still occurs. Would you be game? Would help me really determine the cause.


I’'m game. Just let me know what you need me to do.

Is there any update on this? Is this problem related to SPARK-233 ?

Hi Caleb,

Spark- 223 was would freeze the computer when using the File Opener with unconnected network drives. Was this what they were trying to do as well?


No, I’‘m afraid that wasn’'t what was happening here.

After some testing I have some more info.

I removed the users profile from their workstation and off of our server (it’'s a roaming profile). I then had them log-on. This created them a brand new profile. Spark works with no problems.

Another interesting thing is the problem doesn’'t occur until the user has authenticated with the server. So, if the user is at the logon screen (where it says username, password, server, etc…) everything will be fine. Once the user logs on, processor utilization goes to 100% and the whole system is bogged down until the user logs out or Spark is closed.

I figured out what is causing the slowdown. This is totally bizarre.

Create a shortcut on your desktop (right-click on the desktop -> new -> shortcut)

Now where it says type the location of the item, enter the path to your desktop, so for example enter C:\Documents and Settings\JohnDoe\Desktop

Then click next, and then name the shortcut something, I left it as “Desktop”. Then click Finish.

The new shortcut will have the “Show Desktop” icon.

Now that the shortcut is created, start spark. It will run at 100% processor utilization.

So it should be this thread:

“Thread-17” prio=6 tid=0x02f60d10 nid=0x5c8 runnable

at sun.awt.shell.Win32ShellFolder2.copyFirstPIDLEntry(Native Method)

at sun.awt.shell.Win32ShellFolderManager2.createShellFolderFromRelativePIDL(Unknow n Source)

at sun.awt.shell.Win32ShellFolder2.getLinkLocation(Unknown Source)

at sun.awt.shell.Win32ShellFolder2.isDirectory(Unknown Source)

at sun.awt.shell.Win32ShellFolderManager2.get(Unknown Source)

at sun.awt.shell.ShellFolder.get(Unknown Source)

at com.sun.java.swing.plaf.windows.WindowsFileChooserUI.updateUseShellFolder(Unkno wn Source)

at com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponents(Unknown Source)

at javax.swing.plaf.basic.BasicFileChooserUI.installUI(Unknown Source)

at com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installUI(Unknown Source)

at javax.swing.JComponent.setUI(Unknown Source)

at javax.swing.JFileChooser.updateUI(Unknown Source)

at javax.swing.JFileChooser.setup(Unknown Source)

at javax.swing.JFileChooser.(Unknown Source)

at com.jivesoftware.spark.filetransfer.SparkTransferManager$5.construct(SparkTrans ferManager.java:216)

at com.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:121)

at java.lang.Thread.run(Unknown Source)

I don’'t have the filetransfer plugin installed … so these seem to be some basic Spark classes which cause the problem and which enable basic file transfers.