Hello XMLBlaster folks,
I'd like to thank you for contribution with XMLBlaster. It is a wonderful
product, and it seems to be on its way to becoming an industrial strength
messaging server.
We have been testing out XMLBlaster 0.84 and we ran into the following
difficulties. We were wondering if you had seen these before and if
you had
any suggestions:
1) Difficulties with database persistence: we are using a Postgres
database
to act as persistent storage. Every so often (around 1/100 times
during our
tests), XMLBlaster will throw the following error:
java.sql.SQLException: ERROR: Cannot insert a duplicate key into unique
index pg_class_relname_index
at
org.postgresql.core.QueryExecutor.execute(QueryExecutor.java(Compiled
Code))
at org.postgresql.jdbc2.Statement.execute(Statement.java(Compiled
Code))
at org.postgresql.jdbc2.Statement.execute(Statement.java(Compiled
Code))
at
org.postgresql.jdbc2.Statement.executeUpdate(Statement.java(Compiled
Code))
at
org.xmlBlaster.util.queue.jdbc.JdbcManager.update(JdbcManager.java(Compiled
Code))
at
org.xmlBlaster.util.queue.jdbc.JdbcManager.createQueueTable(JdbcManager.java
:1394)
at
org.xmlBlaster.util.queue.jdbc.JdbcManager.addFreeTables(JdbcManager.java:51
4)
at
org.xmlBlaster.util.queue.jdbc.JdbcManager.getTable(JdbcManager.java:319)
at
org.xmlBlaster.util.queue.jdbc.JdbcQueuePlugin.initialize(JdbcQueuePlugin.ja
va:76)
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.ja
va(Compiled Code))
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.ja
va:59)
at
org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.initialize(Cache
QueueInterceptorPlugin.java:146)
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.ja
va(Compiled Code))
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.ja
va:73)
at
org.xmlBlaster.engine.TopicHandler.startupHistoryQueue(TopicHandler.java:289
)
at
org.xmlBlaster.engine.TopicHandler.administrativeInitialize(TopicHandler.jav
a:235)
at
org.xmlBlaster.engine.TopicHandler.publish(TopicHandler.java:457)
at
org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1479)
at
org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1319)
at
org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1313)
at
org.xmlBlaster.engine.XmlBlasterImpl.publish(XmlBlasterImpl.java:164)
at
org.xmlBlaster.protocol.xmlrpc.XmlBlasterImpl.publish(XmlBlasterImpl.java:12
2)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:40)
at java.lang.reflect.Method.invoke(Method.java:335)
at org.apache.xmlrpc.Invoker.execute(Unknown Source)
at org.apache.xmlrpc.XmlRpcServer$Worker.executeInternal(Unknown
Source)
at org.apache.xmlrpc.XmlRpcServer$Worker.execute(Unknown Source)
at org.apache.xmlrpc.WebServer$Connection.run(Unknown Source)
at org.apache.xmlrpc.WebServer$Connection.run(Unknown Source)
at org.apache.xmlrpc.WebServer$Runner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:566)
2) Deadlock: XMLBlaster clients occasionally appear to enter into
deadlock,
under certain simultaneous usage patterns. Other non-deadlocked
clients seem
to be able to connect and continue processing. One culprit may be
postgres,
although I am unsure.
3) Difficulties with large messages: some of the messages we send are 2
megabytes in size. If there are about five clients publishing messages of
this size simultaneously, meaning a total of 10 MB in motion, the
server may
throw an out of memory exception, even when the JVM is set to use 256
MB of
memory. If there are any property settings or other configuration settings
that would help with this, please let us know. If XMLBlaster is not
supposed
to be used with such large messages, or if we must figure in a 26x memory
factor in deployment, please let us know.
4) Large amounts of data in persistent storage: Suppose we publish 500 MB
worth of messages into XMLBlaster with persistence flagged. XMLBlaster
accepts these messages and writes them to persistent storage with no
problem. However, if we stop and restart XMLBlaster, it attempts to reload
the messages from persistent storage and eventually runs into
memory-related
errors (on our 256 MB virtual machine). Again, if there are any property
settings that will help with this, please let us know.
Again, we thank you and commend you for a fine product, and if you
have any
ideas about these issues, please let us know.
Take care,
Lance Thomas