Lightstreamer Performance Issues while fetching data from db

Hello,

I'm running LS Moderato on a RedHat Enterprise based server.
I've built a multithreaded adapter which has two threads:

1. A thread Contacts a MySQL database using the latest Connector/J Jar every fixed interval , it retreives some data and pushes that data to users if it has been changed.
(I'm using a ConcurrentHashtable to cache results)
2. A Thread that pushes the server's time and date every second

Now, I'm not sure why, and I tried tweaking the code many times and changing the version of the connector /j as well but at certain point
the java binary rises to 150% cpu usage (multi core environment) , and LS becomes unresponsive, any ideas what may cause that (aside from the adapter code, which works without a hiccup under win2k8 environment)

Any known problems whilst using mysql w/ LS under linux?

Thanks beforehand, Max.

You can try to identify the linux lightweight processes which consume most CPU (with the -L option on ps),
then find them on a JVM thread dump taken on Lightstreamer Server and see whether they belong to the kernel or to external code.
Note that the LWP id is listed as decimal by ps and as hexadecimal by the JVM.

One known case is when one reuses HashMap object instances supplied to update or smartUpdate (which is not allowed, though).
We noticed, in some cases, that a HashMap got corrupted and this gave rise to an endless loop when calling a harmless HashMap method.

So HashMap objects are not allowed to be supplied as the 2nd parameter of smartUpdate() ?

Since it can recieve a Map descendant object, or am I getting this all wrong?

Thanks again

You can supply HashMap objects as the 2nd parameter of smartUpdate.
The only restriction is that you have to use a brand new HashMap object instance on each invocation. Put in a more general way, once a HashMap object is supplied to smartUpdate, you can no longer use it.
Depending on what you get from your feed interface, you may have to perform some copy or clone operation.

However, Map objects which are not also HashMap objects are not subject to the restriction.
(I'm not sure if this also answers your second question).