Habarisoft introduces dynamic connection pooling with the next release of its message broker client libraries for Delphi and Free Pascal. Connection pools save resources in multi-threaded applications, as connections are initialized only once and then shared between threads. They can speed up the program execution because the pool returns and stored them in started state.
With the current release of Habari Client for HornetQ, Delphi and Free Pascal applications can send messages to a HornetQ message broker at a rate of more than 11000 to 12000 messages per second (less than 80 microseconds per message) – on very modest hardware and running the HornetQ server on the same system, even while receiving more than 1000 messages per second from the same broker.
The next release will introduce support for STOMP level 1.2 and the HornetQ 2.3.0 open source message broker.
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.
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)
- Home page:
- Documentation (PDF):
- API documentation (HTML):
Firebird developers can use Firebird events to notify clients about changes in database record data. In the previous post, I showed and discussed some limitations of Firebird events. This post presents a solution based on message-oriented middleware.
The solutions in the first post used server-side logic in the Firebird database metadata, implemented with Firebird’s procedural language (PSQL). Information which can not be passed within Firebird events, such as the record ID of the new purchase order, can be stored in helper tables which then must be read by the database clients. So from a technical view, these solutions only replace the timer-triggered client-pull with event-triggered client-pull. This is a small step forward, at the price of increased complexity of database metadata.
A new strategy: implementing the event notification on the client side
Obviously, the client application which inserts a new purchase order could also send notifications to the other clients. The advantage would be that server-side PSQL code can be replaced by code written in your client-side programming language (Delphi/Free Pascal, C#, …). The PSQL code in the server-side solution looked like this:
CREATE TRIGGER PURCHASE_ORDER_INSERT FOR PURCHASE_ORDER AFTER INSERT AS BEGIN POST_EVENT 'purchase_order_table_updated'; END
If we implement notifications in the client side application, similar code has to be be executed when a new order record has been inserted in the order table, using an inter-process communication method. The event notification code could look like this:
procedure TAppDataModule.PurchaseOrderAfterPost(DataSet: TDataSet); var Notification: INotification; begin Notification := NotificationService.CreateNotification(PURCHASE_ORDER_TABLE_UPDATED); Notification.SetIntProperty(PURCHASE_ORDER_ID, PurchaseOrderID.AsInteger); NotificationService.Send(Notification); end;
But advanced features like load balancing, or for notifying clients which currently are not listening, would need a high amount of custom code. Another difficult task would be the integration of clients or other systems written in an other programming languages (a PHP based order entry web app for example) – their integration with your application would only be possible after porting the notification system.
Firebird developers can use Firebird events to notify clients about changes in database record data. In this article, I will show and discuss some limitations of Firebird events and compare possible workarounds with a solution based on message-oriented middleware.
How should I implement “server push” for new data, instead of “client pull”?
For this article we assume a common business use case:
- a two-tier client-server application
- one client creates new records of type “purchase order”
- other clients need to be notified about new “purchase order” records
In this scenario, repeated pulling data from the “purchase order” table causes network traffic from all client workstations – even if there are no new orders at all, and too many clients would cause network and/or server resource overload. But being a two-tier architecture, there is no service layer or application server between database and the client software which could handle the notifications. Our conclusion is that we need server side ‘push’ notifications, which will only cause network traffic when there is new data.
Habarisoft offers a special discount on software assurance for existing users of Habari Client libraries for Delphi and Free Pascal for the message brokers ActiveMQ, HornetQ, OpenMQ and RabbitMQ: two years additional software assurance are available with a 25% discount when the coupon code ‘habari251112′ is used with your purchase. This offer is limited until November 30, 2012.
A minor version update of Habari Client libraries is available. It includes a fix for the Synapse communication adapter which was introduced in the last major release.
Registered users can download these new versions from the download area:
JBoss Community released HornetQ 2.3.0.Beta, which contains HA replication as well as many other fixes and enhancement. Apart from a few minor fixes and documentation updates this is what will go into 2.3.0.Final and is what will be in JBoss AS 7.2. HornetQ now also supports STOMP 1.1. A Delphi and Free Pascal client library for HornetQ is available.