Another interesting performance benchmark post by Roberto Schneider, comparing Java and Delphi implementations:
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.
API documentation (HTML):
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: http://www.habarisoft.com/habari_hornetq.html
- Documentation (PDF): http://www.habarisoft.com/download/HabariHornetQGettingStarted.pdf
- API documentation (HTML): http://www.habarisoft.com/habari_hornetq/1.9/docs/api/index.html
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
- Module 5: RabbitMQ Advance Development
Roberto Schneiders published and discussed test results for a REST application implemented with the frameworks DataSnap, mORMot, Jersey/Grizzly, ASP.NET WCF and Node.js: DataSnap analysis based on Speed & Stability tests. All the source code of the servers, as well as the binaries and the JMeter test plans are available for download at https://github.com/RobertoSchneiders/DataSnap_REST_Test.
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.
Phil Hess posted a step-by-step introduction to Android development using Free Pascal and the Eclipse IDE.
With this solution, developers have access to practically the entire Eclipse and Android toolsets. This includes not only the complete set of Android widgets and a graphical designer for laying them out, but also access to the complete Android runtime. The Eclipse IDE will also build the executable and launch the Android emulator (using Run As | Android Application).
You use a Java class the same way you use Pascal classes. For example, to use the SQLiteDatabase class to open a SQLite database, you would write something like this:
var FileName : string; Db : ADSSQLiteDatabase; begin FileName := 'mydb.sqlitedb'; Db := ADSSQLiteDatabase.openDatabase(FileName, nil, ADSSQLiteDatabase.OPEN_READONLY); ...
This code example shows the Pascal source for an Android activity:
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.