This article shows how Delphi can use IP multicast to discover running Apache ActiveMQ message brokers in the local network. The code has been tested with Internet Direct (Indy) 10.6, which is the version included in Delphi XE4, and Apache ActiveMQ 5.8, which is the current release of the open source message broker.
With the code below, a Delphi application can list all ActiveMQ brokers, see their status, and get their IP address. This allows for dynamic configuration of client applications (built for example with Habari Client for ActiveMQ), where systems do not need to know the location of message brokers. It also allows automatic handling of broker failures or maintenance windows without intervention.
The output shows that a broker was found, running on the computer ‘my-PC’. The URL part indicates that the broker provides a connector for the OpenWire protocol on port 61616.
Waiting for broker discovery messages ...
GlassFish 4 – the first Java EE 7 application server – has been released. It is open source and available for download here – in two versions (Full Java EE platform and the Java EE Web Profile with reduced resource footprint) for Windows, Solaris, Linux and OS X.
New features include standardized API support for the WebSocket (JSR 356) and JSON (JSR 353) specifications, HTML5 support in the JavaServer Faces version 2.2, JMS 2.0, a Batch processing API (JSR 352), Concurrency support, and more. See also: GlassFish 4 Brings Java EE 7
Delphi and Free Pascal applications can be integrated in GlassFish (Full Java EE platform) web applications and web services using the Habari Client libraries from Habarisoft, which provide direct communication with the Open Message Queue (Open MQ) message broker, which is the default JMS provider in GlassFish 3 and 4.
This article shows the code for a Delphi server which receives a RPC call message from the inbound RabbitMQ request queue, and sends the response message back to the Java client. It is the mirror code for the previous article.
But access to the RPC server process is not limited to Java applications – Delphi and Free Pascal applications using the Habari Client for RabbitMQ library can invoke the server process method too.
This article shows the code for a Delphi client which sends a RPC call message to the inbound RabbitMQ request queue, and receives the response message over a temporary queue, which exists only for the duration of the connection.
April 2, 2013 – Habarisoft is pleased to announce release 2.0 of Habari Client for HornetQ. HornetQ is an open source project from the JBoss Community to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system. HornetQ is the default Java Message Service (JMS) provider in JBoss Application Server, but can also used stand-alone.
This library provides Delphi and Free Pascal developers access to production-ready and industry standard based cross-platform application integration, using the peer-to-peer or the publish/subscribe communication model.
Habari Client libraries provide access to production-ready and industry standard based cross-platform application integration, using the peer-to-peer or the publish/subscribe communication model. They are available for the open source message brokers ActiveMQ, Apollo, HornetQ, OpenMQ and RabbitMQ.
December 18, 2012 – Habarisoft is pleased to announce release 1.9 of Habari Client for HornetQ. HornetQ is an open source project from the JBoss Community to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system. HornetQ is the default Java Message Service (JMS) provider in JBoss Application Server, but can also used stand-alone.
Habari Client libraries provide access to production-ready and industry standard based cross-platform application integration, using the peer-to-peer or the publish/subscribe communication model.
New in version 1.9:
tested with HornetQ 2.3.0.Beta2 (released November 22, 2012)
support for configuration parameters in broker URLs, like failover://(stomp://broker1:port?param1=a,stomp://broker2:port?param2=b)?reconnectParam=value&…
tested with revision 4889 of Indy 10.5.9
added documentation on “How do I use synchronous Receive from multiple destinations?”, “ISAPI modules” and “GUI application detection using System.IsConsole” in the “Limitations” chapter
message size limit for text messages is MaxInt octets, the indy.maxlinelength connection URL parameter introduced in version 3.2 is no longer required
the library no longer configures extended RTTI (fixed in patch release 1.8.2)
Synapse: fixed constant 200 ms timeout bug (fixed in patch release 1.8.1)
SpringSource has released a free 2.5 hour eLearning training called vFabric RabbitMQ Fundamentals. This 2.5 hour eLearning training introduces you to the RabbitMQ product, why people use messaging, and how RabbitMQ high availability and clustering works. The training consists of five modules:
Module 1: Introduction to Messaging and AMQP
Module 2: RabbitMQ Product Presentation
Module 3: RabbitMQ Development
Module 4: RabbitMQ High Availability and Clustering
Update: Indy HTTP server tests with pretty good results
To see wether Indy or DataSnap is the bottleneck, I ran a single-threaded JMeter test of the Indy HTTP server on a quite slow system (Mobile Core2 Duo @ 2.1 GHz), with HTTP 1.1 keep-alive enabled. The average throughput was 320 requests/second, with zero (0) % HTTP errors. The CPU load was around 40%, Client and server where running on the same system. In the tests described above, DataSnap with Indy as HTTP transport reached 62 requests/second on a Core i5 750 with 4 x 2,67 GHz system. With 50 threads, throughput reached more than 1.400 requests/second (over 1 million requests), 50% CPU load and 3 MB RAM usage.
The server application was the BasicDemo (a simple ‘Hello world!’) web application implemented with the Habari Web Components, which are a layer on top of Indy HTTP server components.