Pausing Progress Sonic ESB Service

I recently needed a feature in Sonic ESB where the ESB Service needed to be paused for a period of time.

For the versions of ESB until v7.6, I could not pause the service and leave the messages in the entry point (queue in my case). In v7.6, which is the current version, the interface, XQLifeCycleManager, provides a start/stop functionality.

So, for the previous versions, in the service method, I paused the service before it handles the message as:

synchronized (SERVICE_LOCK) {

if (processMessages==false) {

xqLog.logDebug("entering service lock at:"+new Date());

while (processMessages==false) {

try { SERVICE_LOCK.wait(SERVICE_LOCK_PERIOD); } catch (InterruptedException e) { } }

xqLog.logDebug("exiting service lock at:"+new Date());

} // processMessages

}


while (serviceContext.hasNextIncoming()) {

}

Testing the disk-write affects for Progress SonicMQ

When using Progress SonicMQ, you can get different performance results on different platforms. Some of these differences can be explained with the disk setups used for the recovery logs. The documentation, mq_tuning.pdf, that comes with the installation has very good explanations for some of the general factors on pages 79 and 82, and I would recommend it as a reading if evaluating performance issues.

One of the issues, disk-caching, performed by the OS can be the factor you might be looking for. As the documentation indicates, the cache can increase performance but also might cause data-loss in case of failure. On a laptop windows XP system, the config screen might look as in the attachment. To evaluate your system, Progress provides a very useful stand-alone, pure-java testing code for disk performance simulating the real usage from their code-share site. I am attaching the code for quick review but the full package can be retreived from the Progress site.

http://docs.google.com/Doc?id=dxbpvf5_0hnjfxwk2

The line "fd.sync();" is the actual place where the cache matters. You can run the test with this commetted out and see much different results especially if caching is enabled.

Although other factors, like disk block size, remote-disks, disk speed, queue save thresholds can be tuned, the disk-caching can be tested fairly fast and easily to see it affects.