RE: [xmlblaster] Durable QoS performance

[Doug.Palmer at csiro.au]

> have you tried Heinrichs persistence layer already instead
> of the primitive FileDriver?

I've just tried this. This produces a really, really noticable increase in
performance -- after a few set up huccups, I was warned against BLOBs, but
couldn't resist trying anyway. With oid group names and non-volatile
messages I get.

Size    MPS     Sndrs   Rcvrs   Grps    Time    Sent    Rcvd    STpt    RTpt
4096    10.0    10      1       1       120032  1200    1201    10      10
4096    20.0    10      1       1       120048  2400    2401    20      20
4096    30.0    10      1       1       120048  3610    3605    30      30
4096    50.0    10      1       1       120032  5411    5402    45      45
4096    50.0    10      1       1       120032  5818    5809    48      48
4096    100.0   10      1       1       120063  4463    4454    37      37

However, running the test, I get lots and lots of exceptions, on the server
side, of the form:

java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Unknown Source)
        at org.xmlBlaster.engine.xml2java.XmlKey.toXml(XmlKey.java:256)
        at
org.xmlBlaster.engine.persistence.xmldb.XMLDBPlugin.store(XMLDBPlugin.java:1
29)
        at
org.xmlBlaster.engine.MessageUnitWrapper.<init>(MessageUnitWrapper.java:109)
        at
org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1148)
        at
org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1032)
        at
org.xmlBlaster.engine.XmlBlasterImpl.publish(XmlBlasterImpl.java:138)
        at
org.xmlBlaster.protocol.corba.ServerImpl.publish(ServerImpl.java:108)
        at
org.xmlBlaster.protocol.corba.serverIdl.ServerPOA._invoke(ServerPOA.java:80)
        at
org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:207)
        at
org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:404)
        at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:513)

toXml() is obviously something frowned upon by XmlKey for some reason and
it's obviously something needed by xindice. It looks to me like toXml() has
been recently deprecated and the xindice code hasn't quite caught up. But
what would I know?

Since having the log window open slows the system down to a crawl, with all
the stack dumps, I would think getting rid of whatever code mismatch is here
would cause the system to fly.