My favorites | Sign in
Project Home Downloads Wiki Issues Source
Project Information
Members
Links

A reliable Java messaging broker that requires no configuration, yet provides full instance and node failover, and automatic high-availability clustering, again with no configuration required. Simple, fast, and reliable messaging with JetStreamQ. It compiles down to one JAR, and has no dependancies on any other JAR files or libraries except for Oracle's JMS API JAR file.

-Simplicity and productivity are most important

-Reliable - and fast - messaging with no setup required

-Supports JMS Pub/Sub (Topic) and Point-to-point (Queue) based messaging with persistence and reliability

-High-availability clustering is handled automatically, out of the box, without any configuration required

Installation

-Designed to be as simple as it is reliable, JetStreamQ consists of just one JAR file

-There is no installation required

-Simply import JetStreamQ’s JAR file and the message broker runs embedded within your application

-Optionally, you can run JetStreamQ as a standalone process with the scripts included (for Windows, Linux, Solaris, and Mac OS X)

-Most of the JMS API implemented

-What’s not: Transactions, Message Selectors, QueueBrowser

Configuration

-JetStreamQ requires no configuration

-No configuration files or complicated administrative interface

-All running JetStreamQ instances auto-discover each other and then self-configure

-Each JetStreamQ node works as part of a cluster, again without any time-consuming configuration required

JNDI Server

-Initial Context Factory URL:

  com.allure.JetStream.jndi.JetStreamInitialContextFactory

Sample code:

 Hashtable env = new Hashtable();
 env.put("java.naming.factory.initial",
         "com.allure.JetStream.jndi.JetStreamInitialContextFactory");
 Context jndi = new InitialContext(env);
 ConnectionFactory conFactory =
    (ConnectionFactory)jndi.lookup("
 // Create a JMS connection
 connection = conFactory.createConnection("user","password");
 session = connection.createSession(
     false, Session.AUTO_ACKNOWLEDGE);
 topic = session.createTopic( topicName );
 producer = session.createProducer(topic);
 

Message Persistence

-Persisted messages are saved to an internal database

-By default, the database journal files are stored in the current user’s home directory

-For example: ~/jsjournal on Unix

-The default location can be changed via command-line:

  java -DJetStream.persistfolder=/myfolder ...

Automatic Failover & High Availability

-One instance per computer runs as the “server”

-Other instances automatically serve as “stand-by”

-If the server instance shuts down for any reason, one of the stand-by instances takes over seamlessly

-All persisted messages are preserved (must be the same user account or specified directory)

-Reliability is maintained

-Across computers, persisted messages are replicated automatically (note: this can be disabled)

-All computers running JetStreamQ instances are automatically clustered (note: this can be disabled)

-If one computer fails, one of the remote JetStreamQ instances automatically recovers and delivers its messages

-No lost or duplicated messages upon failure or recovery

Scalability

-Designed to scale to multi-core/processors

-Designed to never starve a single queue or topic

-Fast senders for one Destination do not starve other Destinations

-Large messages are automatically compressed

-This is tunable

-Designed to work well with modern garbage collectors

-Low heap overhead even when stressed
-Major GC events are rare even when 100% utilized
-Low-memory: senders are halted, receivers continue
-Measured with CMS collector - small pauses

Tuning Parameters

-Although tuning is not required, it may be desirable in some cases. The following pages list the available command-line parameters.

-Repeatedly add them to the Java command-line as such:

 java -DJetStream.queuesenders=16
   -DJetStream.logtostdout=true ...
 

Parameter name Default value Description
-DJetStream.logtofileTRUEBy default, all log messages are saved in the file jetstreamX.Y.log. When set to FALSE, log messages aren’t saved. The value X is a unique value if multiple instances are started. Value Y is the file count if rollover occurs.
-DJetStream.logtostdoutFALSEWhen set to TRUE, internal log messages are replicated to standard out.
-DJetStream.logallFALSEWhen set to TRUE, verbose logging is turned on. WARNING: This option greatly impacts performance
-DJetStream.logappendTRUEWhen set to TRUE, new log messages will be appended to the existing log file upon start up of JetStreamQ.
-DJetStream.logfilesize10,000,000The maximum size of the log file before it gets rotated. The latest log file is always jetstream0.0.log.
-DJetStream.logfilecount30The maximum number of rotated log files stored. The file with the largest number before “.log” is the oldest.
-DJetStream.logfilepath./The directory (with path) used to store the log files. By default, it’s the same directory JetStreamQ is started in.
-DJetStream.haTRUEBy default, high-availability mode is on. As a result, all persisted messages are replicated to each remote JetStreamQ instance on the network. Setting this to FALSE turns off replication, and hence disables high-availability. In cases where HA is not desired or needed, setting this parameter to FALSE will increase performance and reduce network traffic.
-DJetStream.persistfolder~/jsjournalYou can change the default directory for persisted message storage by specifying a path here. Regardless of the path you specify, the text “/jsjournal” will be appended.
-DJetStream.serverallowedTRUEBy default, each instance of JetStreamQ on a computer can run in server mode. This enables automatic failover between instances. If you don’t want a particular JetStreamQ application to run in server mode, set this to FALSE. Warning: this will impact message delivery if there are no other instances available to run in server mode.
-DJetStream.qsenders8Point-to-point message delivery is handled by a pool of dedicated internal worker threads. Use this parameter to change the default number of threads.
-DJetStream.topicsenders8Publish/subscribe message delivery is handled by a pool of dedicated internal worker threads. Use this parameter to change the default number of threads.
-DJetStream.psthrottle1,000,000To ensure a single fast publish/subscribe message producer cannot consume all server resources, the sender will be blocked when the total number of undelivered messages equals this value. It will be unblocked when the message count decreases below this value, plus a margin of 50
-DJetStream.compressTRUEBy default, messages will be compressed when they exceed a specific size (see -DJetStream.compressthreshold). This saves network bandwidth, which can quickly become a bottleneck in message delivery performance. To turn off message compression, set this to FALSE.
-DJetStream.compressthreshold1024If message compression is turned on, message data is compressed for messages that exceed the specified size in BYTEs.
-DJetStream.compressSpeedTRUEBy default, compression speed is favored over size (the amount of compression). To compress messages as much as possible, trading off some performance, set this to FALSE. Use this only if you’ve determined that network bandwidth is a bottleneck, not CPU.

Scripts and Requirements

-For Unix-based systems (Solaris, Linux, Mac OS X):

- jetstream.sh

-For Windows-based systems

- jetstream.bat

-Works with Java SE 5, 6, or 7

Contact

If you have questions, contact Eric Bruno at:

eric@alluretechnology.com

Powered by Google Project Hosting