Troubleshooting
Here are some problems people have encountered, and the solutions.
NoClassDefFound errors for java.util.StringBuilder
Symptom: When you execute your code on Mika you get these errors even though you never reference java.util.StringBuilder in your source.
Cause: If you compile Java code for Java5, every time you use the + operator between two strings the compiler will emit code which uses java.util.StringBuilder. This class is new in Java5, and so not supported by Mika.
Solution: Compile with target=1.4, which will cause the older java.lang.StringBuffer to be used instead.
Unable to run Mika on linux-ia64 (crashes immediately on startup)
Symptom: On 64-bit Linux platforms, Mika crahes with a segfault or similar immediately after launching.
Cause: Mika is designed for 32-bit processors and is coded on the assumption that e.g. a java int, a java float and a native pointer are all the same size (32 bits) - on a 64-bit platform this assumption is violated.
Solution: You have several options.
1. Install ia32-lib on Debian, or the equivalent on other distributions. This should be sufficient to run the Mika executable.
2. If you use other native libraries beyond the ones used by Mika itself then it may be better to install a 32-bit Linux kernel and userland which runs "inside" the 64-bit one, using chroot, or better still schroot. This is also the easiest way to build Mika on a 64-bit system; simply install gcc in your 32-bit chroot and compile in that environment. Read all about this at The Debian GNU/Linux AMD64 HOW-TO.
3. Alternatively you can install your favourite virtualiser - Xen, Qemu, VMWare, whatever - and run a 32-bit Linux on it. Using this technique may also make it easier to simulate some other aspects of your target system such as memory size, networking environment, etc..
Note: As yet there are no plans to make Mika 64-bit capable. The embedded cpu architectures at which it is targeted are all 32-bit, and supporting both 32-bit and 64-bit architectures would increase complexity and the risk that what works on one architecture will fail on another.
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.
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.
The following procedure is recommended in order to keep problems to a minimum:
- Boot the device: the clock is set to 1/1/1970
- Start Mika but do not execute any code which creates timer tasks - all threads which will do this should wait() on a monitor
- When ntp synchronisation has taken place, notify() the monitor so that these threads can proceed.
Of course you can also use other mechanisms such as checking that the system date is "sane" before launching any timer tasks - but don't use a timer task to do this!
