Stability of Wuala client is a pain

I’m using the wuala client since one week with the idea to migrate all of my relevant data to the wuala cloud. Additionally I’m sharing some local space and bought some additional space to support the wuala team.

From the concept view I’m very pleased with wuala.I really like the client. The idea and usability of the wuala client is very good, simple to use and yet powerfull enough to tweak some performance. Integration into the host operating system as local share works also fine.Working offline is also cool and performance also. The client performs fine as long you play around with less files.

Now comes the but. A very big BUT. In case you store some GB of data with 10.000 and more files you get a mess. I had since last week about 6 Java exceptions killing the client and some crashes without even an error message. This is not what I excpected.

To be honest, I never lost a file. Only when I uploaded in offline mode files via the “W:” share I lost the files (locally and in the cloud). I will try to validate this later and create a ticket for it.

At the moment I’m not sure that the idea to migrate to wuala was a clever move because of the maturity of the client! I’m very sorry for this words. A stable, trustful client is more important than some cloud features! If you can’t guarantee that e.g. the “Ctrl-E” feature works 100% perfect don’t deploy it! If you know, that uploading 200MB with 20.000 files via “W:” exceeds eventually the JVM Memory then don’t do it. I had the same troubles under Windows Vista and Windows 7. Mac OS is bit more stable.

Right now I’m very upset with the situation. The combination JungleDisk & Amazon S3 had in 2 years not one crash with the same data!!

Here is one example of my annoyance after downloading some files into the cache:

com.wuala.common.exception.ApplicationRuntimeException: Failed to execute runnable (java.lang.StackOverflowError)
at com.wuala.obfuscated.TZ.i(Z:197)
at com.wuala.obfuscated.yJ.a(Z:265)
at com.wuala.obfuscated.yJ.a(Z:128)
at com.wuala.platform.Wuala.launch(Z:28)
at com.wuala.loader2.Loader2.startInstance(
at com.wuala.loader.SplashScreenLoader.main(
Caused by: org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.StackOverflowError)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source)
at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source)
at com.wuala.obfuscated.yJ.a(Z:374)
at com.wuala.obfuscated.yJ.a(Z:222)
… 4 more
Caused by: java.lang.StackOverflowError
at java.util.AbstractList$ Source)
at com.wuala.common.exception.FeedbackException.isIgnorable(Z:85)….


4 thoughts on “Stability of Wuala client is a pain

  1. Hi coffeemug13,

    the bug you mention will be fixed in the next release (according to Luzi). Unfortunately, the file system integration is a part of Wuala that is not yet ready for the kind of heavy use you’re putting it to. Historically, FSI was used to implement double-click editing and streaming of media file directly from Wuala. While we are working towards making FSI work better under heavy load, we are clearly not there yet.

    Could you tell us what the problem with “download to cache” is (ctrl-e)? Ideally at

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s