Troubleshooting

Here are some problems people have encountered, and the solutions.

java.net.MalformedURLException: no Handler found for the file protocol

Symptom: Nothing works, the above exception is thrown before Mika even starts running your application.

Cause: You have an old system.properties file or command line which sets the java.protocol.handler.pkgs property to com.acunia.wonka.net.

Solution: Change the property value to wonka.net

Changing system clock causes Mika to lock up

Symptom: When the system clock is set manually, Mika seems to "hang" and fails to respond to control-C. (It is still possible to kill-9 the Mika process).

Cause: If you advance the system clock, some periodic timers may expire multiple times, putting Mika into 100% CPU load (particularly if the clock jumps from 1 January 1970 to the present day). If you set the clock back 'n' seconds, all sleep() and wait() calls are extended by that amount, because Mika uses pthreads and pthreads works internally with absolute clock times.

Solution: Unfortunately there is no easy solution for this, other than "don't do that". Since revision 485 Mika handles the "clock advanced" case better, by detecting that the change has occurred and compensating appropriately in class java.util.Timer. However for the "clock set back" case nothing we have tried works; for example we tried sending a notify to all waiting threads, but the notify seems not to be acted upon until the system clock has "caught up".

Note that this problem also exists in Sun VMs, see e.g http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4290274. However it is less of an issue on desktop or server systems where it is uncommon to change the system clock on a running system (except gradually, as ntpd does).

Note also that you should not need to set the clock forward or backward one hour because of daylight-saving time: set an appropriate timezone using the user.timezone property and let Mika do the work!

If you are building Mika from source, it is possible to edit the Jamrules file to disable the line CCFLAGS += -DHAVE_TIMEDWAIT, thereby forcing Mika to use an alternative mechanism for timed wait() calls. However this alternative mechanism is known not to be 100% reliable - when we run "stress tests" on such a version of Mika we often find that somewhere a thread goes to sleep and never wakes up. (Presumably there a race condition in which the thread "misses its tick"). Therefore we cannot recommend this solution for production systems.

Suggested workaround: If you really can't avoid having the system clock change in a running system (for example because your device has no battery-backed clock and the only way to set the time is via the GUI), then it may be better to keep track of the difference between system time and real-world time in a variable, and compensate inside your application. You could also try to gradually reduce the discrepancy by making incremental system clock changes ntpd-style, but this adds more complexity to your application so it may be simpler to just let it be.