Posted by
seon on Thursday, July 10
This is probably old news, but I still get excited thinking about all the interesting solutions that are possible now using Mule and Gigaspaces for SOA problems requiring low latency and highly scalable architectures.
Gigaspaces released 6.5 with API integration with Mule 2.0 … this is just plain awesome. You can use Gigaspaces as the transport (e.g. in place of JMS) and quickly get a SBA up and running utilizing the same concepts I used at RHG when we were servicing B2B problems. You also get the advantage of the clustering ability and fault tolerance that comes with Gigaspaces – which is just pure sex – not to mention all the other great features that come with this advanced Javaspaces implementation (i.e. management tools, monitoring tools, data partitioning, performance features like batching).
Gigaspaces would have made a fantastic backend transport and shared data grid in place of ActiveMQ JMS, but at the time it wasn’t as fully integrated with Mule. We would have been able to solve alot of the high availability and clustering concerns regarding single points of failure with the messaging database and JMS brokers. I never felt comfortable with ActiveMQ’s clustering and fail-over features. Configuration seemed a bit fussy and it doesn’t seem to be as easy to scale out as a Gigaspace cluster.
Posted by
seon on Thursday, June 19
I’ve encountered a typo in the JMS package from Oracle while I was debugging a problem with multicast routing under Camel and Oracle AQ. It seems that Oracle may have slipped up and misnamed the “JMSXRcvTimeStamp” property as “JMSXRecvTimeStamp”. I don’t have access to the source code for the ORacle’s implementation of javax.jms.Message (AQjmsMessage), however I poked through the class file with a hexeditor and found instances of the typo.
According to the Java JMS 1.1 specification, this is a property that is set by the jms provider when a message is dequeued. The spelling of the property is listed as “JMSXRcvTimeStamp” on page 39 of the spec pdf. Oracle Streams Advanced Queuing User’s Guide and Reference
10g Release 2 document referencfes the correctly spelled property in section 11.2.2 however elsewhere in the same document it is incorrectly spelled. I’m pretty sure this is a bug in Oracle’s implementation of the Message interface. The document for Release 11g shows the same errors.
Additionally, I get the feeling that either Camel, Oracle or Spring is incorrectly setting null values for several standard JMS headers and properties when they are not assigned or not present. If null values are allowable under the JMS spec, then Oracle’s AQjmsMessage.setJMSReplyTo(Destination) should accept null parameters without exceptions also. Right now passing a null Destination value to method setJMSReplyTo(Destination) results in this exception:
|
oracle.jms.AQjmsException: JMS-147: Invalid ReplyTo destination type, or use of reserved `JMSReplyTo agent name, or serialization error with AQjmsDestination org.springframework.jms.UncategorizedJms |
Here is the post I created in the Camel users forum relating to this issue.
Here is the JIRA issue I created for camel-jms: https://issues.apache.org/activemq/browse/CAMEL-618
