ActiveMQ, Ruby, STOMP Transport

ActiveMQ is a popular Enterprise Messaging and Integration Patterns provider. ActiveMQ is designed to communicate over a number of protocols (such as Stomp), and it also supports plenty of cross language clients.

And so here we have a stomp client for ruby, which I found quite easy to use, however quite a few information is available for it.

What you do to use Apache ActiveMQ and the stomp client for ruby?

1, download and install Apache ActiveMQ.
2, download and install rubygems.
3, configure stomp transport in Apache ActiveMQ. In fact, in conf/activemq.xml of your ActiveMQ installation you can see that stomp transport is already configured:



4, writing a message sender using the stomp client for ruby.

#sender.rb
require 'rubygems'
require 'stomp'
client = Stomp::Client.open "stomp://localhost:61613"
client.send('/queue/myqueue',"Hello World!")
client.close

5, writing a message listener using the stomp client for ruby.

#listener.rb
require 'rubygems'
require 'stomp'
client = Stomp::Client.open "stomp://localhost:61613"
client.subscribe "/queue/myqueue" do |message|
puts "received: #{message.body} on #{message.headers['destination']}"
end
client.join
client.close

And so this is it! Just start the ActiveMQ message broker, start the listener (ruby listener.rb), start the sender (ruby sender.rb) and the "Hello World!" message will be transported via ActiveMQ's stomp transport.

Oracle 10g JDBC and Java 5

In addition to the previous bug with Oracle 10g JDBC driver v10.1.0.4 and Java 5, when instead of a very small number a very large number gets inserted, we encountered another bug, which was kind of the opposite. This time the exact version of Oracle driver is 10.1.0.5.

Here's a sample code:

BigDecimal decimal = new BigDecimal("1.03+7");
PreparedStatement stmt = .... 
stmt.setBigDecimal(decimal);
stmt.update("...some sql...");

After the transaction is commited, and we do a query for the result we get .... 10 (!)

inserted 1.03+7 but the result is 10

We cannot rewrite the application, as it already has a lot of Java 5 features in it. One option could be to use retrotranslator and run the application with Java 4. But the problem is that we already use some frameworks that make use of Java 5 API and we cannot overcome the problem just by translating the bytecodes to the older JVM.


Here's the solution I discovered:

When using the scientific notation for instantiating BigDecimal, calling a toString() method will be:

BigDecimal decimal = new BigDecimal("1.03+7");
System.out.println(decimal);

>> 1.03+7

But changing the scale will produce something different:

BigDecimal decimal = new BigDecimal("1.03+7");
System.out.println(decimal.setScale(2));

>> 10300000.00

That's it! You just can set scale for the BigDecimal that you are about to insert into Oracle database :) So far we're good with this solution, although it looks like a crap.

Erlybird: the Erlang plug-in for Netbeans

Erlybird looks very fine while working in Netbeans. Unfortunately Erlide (the Erlang plug-in for eclipse) wasn't that smooth.



The strange thing about the plug-in settings is that it shows itself like if it would be a JRuby plug-in:



What could be done better, I think, is when I run a script, instead of the erl interpreter I could choose a function to be used to start the script. So it could look like any other program I'm running in IDE.

FIX is digging the ESB world

After Apache Synapse got its FIX integration and Apache Camel followed with the FIX endpoint, we can see now same integration done for Mule ESB. It is interesting, that all the products use QuickFIX/J to implement the integration.

What is it? Is it a hype for the ESB world, to include FIX - there must be a trigger for this kind of features. Do the OMS really demand FIX more and more?