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.

Oracle DB User and Password with Turkish Characters

If you have ever put turkish characters in your username and/or password for your DB and tried to use it thru an application, you might have gotten:

java.sql.SQLException: ORA-01017: invalid username/password; logon denied

This is due to the fact that oracle JDBC driver does a local insensetive upper case and therefore the turkish characters gets converted incorrectly.

For example, if your username had 'kaşmir' this should be converted to 'KASMIR' but gets converted to 'KAŞMİR' and therefore not supported.

Increasing Progress SonicMQ Client Performance

Progress SonicMQ is a Java Message Service (JMS) implementation. The client performance can be improved by using prefetch and prefetch_threshold parameters. The default values for the parameters are 3 and 1 respectively.

What these parameters are used for is to reduce the network traffic by grapping 3 messages (if available) from the queue with one network request instead of 1 message per request. The threshold is used for filling the local client buffer before the next message processing requests a message.

One misconception with this is that, if there are two receivers for one destination, and lets say 6 messages in it, the first receiver will get the first 3 messages and the second one will get the next 3 messages from the queue. This does not mean the message is processed, but just retreived from the queue. If the client does not acknowledge these message, they are returned back to the queue.

BEA Weblogic 8.1 and Hibernate 3.x new SQL Parser

Hibernate 3.x uses new sql parser for HQL by default that requires antlr.jar. BEA also uses the same parser for EJB-QL. The problem is that because WL loads the its own version of the jar file before your application, and therefore a different and older version of jar is loaded.

Your application encounters "org.hibernate.QueryException: ClassNotFoundException" for “org.hibernate.hql.ast.HqlToken” even though you include the antlr.jar file from hibernate distribution.

This issue is addressed in the hibernate document site at:
http://www.hibernate.org/250.html

The easy way this can be resolved is by modifying the startWeblogic script and include your own jar file in the beginning of the classpath so yours gets loaded before the BEA’s jar file.

Test Issue

Hello World...standard, what you expect!