[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] OutOfMemoryExceptions



Hi Joshua,

could you please update to the xmlBlaster 1.0.6 to have the JMX support and start it like this
(please use the newest JDK 1.5):


# Start the server
java -Dcom.sun.management.jmxremote org.xmlBlaster.Main

# Start the GUI on the same machine (it is delivered with Suns JDK 1.5):
jconsole

For details see

http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.jmx.html


Now it should be easy to look at the queues, sessions and topics of xmlBlaster and see what
happens in the server.


If everything looks nice (no outdated topic or missing cleanups) you should consider to increase the
server memory with for example:


|  java -Xms18M -Xmx512M |-Dcom.sun.management.jmxremote org.xmlBlaster.Main

I believe that the OutOfMemory is the root reason of your problems so it is essential
to analyse first what is going on in the server.


badly.  Also, is there some way to trap these exceptions on the Perl
side and simply ignore them so that my clients can go on processing?


You shouldn't do this, don't just cover the real problems.

A desing note:
Probably you should consider to rethink your design, avoid using getters (polling) and rather
prefer subscriptions.


Please report your results,

best regards
Marcel





Joshua Bowman wrote:

Hello,

First, my setup:

I have been tinkering with version 1.0.2 of the bus along with the Perl
client API.  I've got several clients connecting, some of them
exclusively publish-ing, others exclusively get-ing.  The get clients
stay connected and issue a get command every few seconds.  The
publishing clients only connect intermittently--a typical push setup.

Each message has an entirely unique oid, and when a client sees an oid
more than once, it issues an erase command.  Multiple clients may be
get-ing that message, because I'm using XPATH queries that only care
about higher-level taxa, i.e., the unique timestamp at the end of the
oid is ignored when making most queries.

Also, I should point out that I am running the middleware without any
persistence.  (I uncommented all the RAM plugin lines in the
xmlBlaster.properties file)  I've also set the message/maxRemainingLife
to 1000 ms and the destroyDelay to 1 sec.  Typical throughput is
somewhere in the range of a hundred messages/minute.

The server is running Fedora Core 3 on a 2 GHz processor with 1 GB of
RAM.

Now, the problem:

The middleware and all clients function perfectly for a couple days and
then I start getting exceptions tossed all over.  Especially by the
get-ing clients.  A few examples:

Fault returned from XML RPC Server, fault code 0: java.lang.Exception:
errorCode=legacy message=#exported DOM tree is invalid

Fault returned from XML RPC Server, fault code 0: java.lang.Exception:
errorCode=user.query.invalid message=#exported Sorry, can't access,
query syntax of '/xmlBlaster/key[contains ( at oid,'<unique id>')]' is
wrong : java.lang.NullPointerException

The middleware gives these exceptions:

[Aug 25, 2005 5:09:35 AM WARN  Thread-10 XmlKeyDom.InvalidQuery] Sorry,
can't access, query syntax is wrong for '/xmlBlaster/key[contains
( at oid,'<same unique id as above>')]' : java.lang.NullPointerException

java.lang.OutOfMemoryError

It appears that the clients are properly deleting messages from the bus,
because when I restart a get-ing client, it doesn't recieve any of the
messages that were sent while it was down.  Are these errors due to some
sort of race condition, or am I really running out of memory?

I'm inclined to believe it is the former, because I'm quite new to
xmlBlaster, and I'm fairly certain that I'm abusing the API pretty
badly.  Also, is there some way to trap these exceptions on the Perl
side and simply ignore them so that my clients can go on processing?

Any help will be much appreciated.

- Josh