RSS feed for InstantSpot site Blog of Dave

Talking through some current issues with ColdFusion Event Gateways

Mon, 09 Nov 2009 16:28:07 GMT

Normally on my blog I attempt to throw out some tip, trick, or nugget of some sort. This time? Not so! I am currently trying to find a solution to a problem at hand and am brainstorming the best way to handle a few things. I am really just talking this out for my own benefit, but I would love to hear thoughts from others that have perhaps solved similar issues.

On a project that I am currently engaged in I am leveraging ColdFusion Event Gateways which work as a subscriber to a SonicMQ JMS server. My gateway instance listens for messages on the ESB (Enterprise Service Bus) on a particular destination name (topic/queue). When it receives a message, it parses the XML that it received, and plays traffic cop pushing data into various services that need it. I have this working flawlessly in my small development environment. However, I have a couple of complexities ahead of me that I am having difficulty coming up with a good solution.

Running in the cloud - Our production environment will have any number of CF instances, not clustered, but rather running as isolated applications with a load balancer directing the requests using sticky sessions. Our system will be bringing new instances on/off line as traffic traffic dictates. I have yet to solve the issue of how to set up my JMS Event Gateway in this environment. I definitely don't want 20 different listeners out there all doing the same work. I have considered the idea of having some sort of a support database where a listener can insert a row with a specific JMS message ID and when any other server picks up a message with that ID it will see that it is already being acted upon and it can safely ignore it. There are a couple of negatives that I can see right off the bat. First is that every single subscribed instance will have to pull in the same message and test to see whether or not it should be acted upon. It just seems like a little bit of redundancy that shouldn't be there. Secondly, there is a chance that two servers could pick up the same request within milliseconds of each other and both could end up doing the work. Duplicate processing could not only be wasteful, but could also create some data integrity issues.
Different environments have different settings (dynamic config) - Right now in our development phase, we have a single config file with setting specific to our development JMS server (credentials, domain, URL, Initial Context Factory, etc). However, soon I will need to have this process support a number of different environments: multiple dev environments, multiple integration environments, multiple QA environments, and eventually production. Ideally it would be wonderful if I could find some way to load a specific config into the event gateway at server init time, but as of today I have _NO_ idea how to solve this one. First, there is no real intrinsic indicator at the server level that lets it know what environment is currently running (yet anyway...) and secondly, ColdFusion event gateway architecture isn't conducive in any way to dynamically loading a specific config.

So now I am counting on you CFML community. Help me brain storm on this! Do you have any thoughts/ideas that might help me here?

Solving java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.

Fri, 08 May 2009 14:24:00 GMT

Recently I have began working with JMS and ColdFusion, in which we are building a system that subscribes to an enterprise JMS server and picks up messages relevant to its needs and acts on them. I had my proof of concept working with the open source Apache ActiveMQ server and was very pleased with the results. However, in our production environment, the powers that be decided to use the very non-free SonicMQ server.

As I tried to convert the event gateway over to the SonicMQ server, it failed on initialization with the following exception:

javax.naming.NamingException [Root exception is java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.]  at com.sonicsw.jndi.mfcontext.MFConnectionManager.connect(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFConnectionManager.<init>(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFConnectionManager.getManager(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFContext.<init>(Unknown Source)  at com.sonicsw.jndi.mfcontext.MFContextFactory.getInitialContext(Unknown Source)  at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)  at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)  at javax.naming.InitialContext.init(InitialContext.java:223)  at javax.naming.InitialContext.<init>(InitialContext.java:197)  at examples.JMS.JMSConsumer.start(Unknown Source)  at examples.JMS.JMSGateway.startGateway(Unknown Source)  at coldfusion.eventgateway.GenericGateway.start(GenericGateway.java:118)  at coldfusion.eventgateway.EventServiceImpl$GatewayStarter.run(EventServiceImpl.java:1428)

In my research on this problem, I found several people reporting similar errors, each on CF8, and each talking to 3rd party tools. Eventually I found the solution through an email discussion between one of the developers in my company and an Adobe developer. Apparently in CF8, they added FIPS security, which disables the Sun JCE (encryption libraries). To solve this error, you need to add the following line to your java.args in your jvm.config file in JRun.

-Dcoldfusion.disablejsafe=true

Now restart your server and try again!

`c->xlib.lock' failed error on Java applications

Tue, 29 Jan 2008 21:16:00 GMT

I am currently using the Alpha 3 release of Ubuntu 8.04 Hardy Heron. Considering the fact that it is an alpha release, I tend to not get worked up over little errors that might occur. However, I have found one that I just couldn't get around. I use Aqua Data Studio for my database client and since loading Hardy Heron, I have been unable to run it.

When I would start it from a terminal, I would get a dump that looked like this:

#0 /usr/lib/libxcb-xlib.so.0 [0x90d00767] #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0x90d008b1] #2 /usr/lib/libX11.so.6(_XReply+0xfd) [0x9039429d] #3 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x9063e8ce] #4 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x9061b067] #5 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so [0x9061b318] #6 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/xawt/libmawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x2f) [0x9061b61f] #7 [0xb4cff3aa] #8 [0xb4cf7f0d] #9 [0xb4cf7f0d] #10 [0xb4cf5249] #11 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d] #12 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x64fd168] #13 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x6373220] #14 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so(JVM_DoPrivileged+0x363) [0x63c90d3] #15 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/libjava.so(Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedAction_2+0x3d) [0xb7d1096d] #16 [0xb4cff3aa] #17 [0xb4cf7da7] #18 [0xb4cf5249] #19 /usr/lib/jvm/java-6-sun-1.6.0.04/jre/lib/i386/server/libjvm.so [0x637338d] java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion 'c->xlib.lock' failed. Aborted (core dumped)

Considering the fact that I used the Ubuntu sun-java6-jdk package from the Ubuntu repository, I decided that I would try the self-extracting bin that is available on http://java.sun.com. After swapping to that JVM, I still received the same dump and abort. After doing a bit of searching, I came across a patch in one of the bug reporting forums that effectively patches your JVM and prevents this error from occurring. I ran the patch and now everything works as it should. If you are receiving this error, create a shell script with the following content and run it. Assuming that it runs successfully, you should then be able to open the Java application that was failing.

#!/bin/sh # S. Correia # 2007 11 21 # A simple script to patch the java library in order # to solve the problem with "Assertion 'c->xlib.lock' failed." # see bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 LIB_TO_PATCH=libmawt.so for f in 'find /usr/lib/jvm -name "$LIB_TO_PATCH"' do echo "Patching library $f" sudo sed -i 's/XINERAMA/FAKEEXTN/g' "$f" done

Big thanks to "S. Correia" for getting me back on my feet!

Installing the JRE plugin in Firefox on Ubuntu

Fri, 18 Jan 2008 13:59:00 GMT

I have now been using Ubuntu for about 2 years, and oddly enough one thing that has always evaded me is how to properly set up the JRE plugin in Firefox. It *seems* like that ought to be an easy process, but it is one of those annoying little things that just hasn't worked for me, although it has never been important enough for me to chase down.

Yesterday I had to do a Webex presentation that required the JRE plugin, so I decided it was time to hack my way through it. One thing that I was thinking my be a factor is that I use Swiftfox instead of Firefox. I decided to take that out of the equation just to make sure, so I went ahead and removed it. When running Firefox and hitting about:plugins in the address bar, I could clearly see that the Java plugin was not in the list. I looked in ~/.mozilla/plugins, and saw a libjavaplugin.so in there, but it was obviously not doing its job.

So, after a lot of floundering, here are the basic steps I took that got me going...

First, I completely uninstalled Firefox:
$ sudo apt-get --purge remove firefox
I then reinstalled it:
$ sudo apt-get install firefox
Next, I had previously installed the sun-java2-bin package, so I wanted to wipe all evidence of that and reinstall it. I did the following:
$ sudo apt-get --purge remove sun-java6-bin sun-java6-jre sun-java6-plugin
To reinistall it I did:
$ sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-plugin
After doing this I opened Firefox and put about:plugins and still didn't see the Java stuff. At this point, I went into my ~/.mozilla/plugins directory. From earlier attempts I had some libjavaplugin.so and libjavaplugin-[something I don't remember].so. I decided to kill those off:
$ sudo rm libjavaplugin*
At this point looking around I found a file /etc/alternatives/firefox-javaplugin.so that seemed like a decent candidate, so I did a symlink like this:
$ ln -s /etc/alternatives/firefox-javaplugin.so ./libjavaplugin.so

At this point I restarted the browser, hit about:plugins and was thrilled to see an entirely new section for Java!

Now, take the steps above with a grain of salt. I certainly don't want to infer that this is by any means the right way to get it working, but it is the series of steps that finally got it working for me. Hopefully someone else might get something out of it as well.

Grand Canyon... It's on!

Mon, 11 Jul 2005 05:00:00 GMT

My father and I decided that this was the year that we would hike the North Rim to the South Rim of the Grand Canyon. I know this seems crazy, but it is actually a paperwork challenge to be able to hike the Grand Canyon. There is an application process in which you have to fax your request in the 1st day of the month 6 months before the intended date of your trip with a detailed itinerary, including where you will be sleeping and when. We sent faxed our paperwork in and held our breath on the 1st of April, 6 months before we hoped to go in September. After no word for a month we finally contacted them, only to find out that we had been rejected. Discouraged, but not beaten, we laid out the calendar to see if there was another time that would work. We decided that November would be acceptable, albeit a little colder. It should be in the 60s in the bottom of the canyon though where we will spend the majority of our time. Once again, we laid out our itinerary and faxed in on July 1. My dad received a letter today dated July 6, 2005 telling him that they were sorry, but they were unable to accept out application. He spent a good hour walking around the house cussing and feeling terribly disappointed. A bit later my mom noticed there was another letter from the Grand Canyon dated July 7, 2005.

Dear Mr. Shuck, we have accepted your request to hike the Grand Canyon on the dates of November 1, 2 and 3, 2005. Enlcosed are your passes, which you will need to affix to your backpack and carry with you in the canyon. There is no need to stop by the back country headquarters before departing on the trail.

So in 3.5 months, I will be taking this in....