wrapper.sf.net
This module integrates TanukiSoftware's Java Service Wrapper [http://wrapper.sf.net] with Q2 in order to start Q2 as an NT-Service (when running in a Windows environment) as well as to control and monitor a running Q2 in a Linux environment (see wrapper's website in order to easily add support for additional platforms).
We provide two different jPOS-EE modules, wrapper_linuxandwrapper_windows.
Both of them provides a wrapper configuration file cfg/wrapper.conf as well as abin/q2wrapper that can be used to start, stop, install and remove the wrapper.
Note
Current configuration assumes that we are running jPOS-EE out of a singlejar, so you have to call
ant singlejar while producing your distribution. If running in 'singlejar mode' is not desirable, you can edit cfg/wrapper.conf in order to add additional jars to the classpath (i.e: wrap-per.java.classpath.n=lib/xxx.jar)
6.3.1. Credits
Bharavi Gade has been of great help in the development and testing of this module in the Windows environ-ment. His feedback has been backported to the Linux version as well.
Experimental
6.4. HA Service
jPOS High Availability Service uses JGroups in order to create a cluster of nodes where one of the node is voted as a MASTERand the rest are SLAVES.
HA Service uses three external scripts that will get called whenever a node becomes a master, becomes a slave, or the cluster changes somehow.
<ha-service class="org.jpos.ha.HAService" logger="Q2">
<property name="group-config" value="cfg/ha.xml" /> (1)
<property name="group-name" value="jPOS-HASERVICE" /> (2)
<property name="up" value="cfg/up.sh" /> (3)
<property name="changed" value="cfg/up.sh" /> (4)
<property name="down" value="cfg/down.sh" /> (5)
</ha-service>
(1) JGroups configuration. cfg/ha.xmluses JGroups' 2.2.8 default.xml configuration.
(2) The cluster's name. Any valid JGroups name would do.
(3) A script to be called whenever a node is elected as the MASTER.
(4) A script to be called whenever the group changes.
(5) A script to be called whenever a node becomes a SLAVE.
It is up to the system designer to create suitableup, downand eventually changedscripts.
These scripts can copy QBean XML descriptors off temporary directories into the deploy directory in order to run the MASTERor theSLAVE.
In addition, we found very useful to use an alias IP address for the cluster, and have the MASTER stand-in using that alias.
Sample up.sh script
/sbin/ifconfig eth0:10 192.168.1.10
send_arp eth0 192.168.1.10 001122334455 192.168.1.10 ffffffffffff
Sample down.sh script
/sbin/ifconfig eth0:10 down
6.4.1. Credits
Dave Bergert has been instrumental in the development, testing and fine tuning of jPOS HA Service. He's also in charge of several mission-critical jPOS based clusters using it.
6.5. ReplicatedSpace
ReplicatedSpace is a distributed/replicated Space implementation that uses JGroups for its underlying com-munication.
Experimental
Note
This is an experimental jPOS-EE module. Use it at your own risk.
6.5.1. Usage
In order to use the ReplicatedSpace you need to deploy a simple QBean like this:
<rspace class="org.jpos.space.ReplicatedSpaceAdaptor" logger="Q2">
<property name="space" value="tspace:rs1" /> (1)
<property name="rspace" value="rspace:rspace" /> (2)
<property name="group" value="rspace" /> (3)
<property name="config" value="cfg/jgroups.xml" /> (4)
<property name="trace" value="true" /> (5)
</rspace>
(1) The ReplicatedSpace uses a local space as its underlying storage. You can use for example a tspace or a
jdbmkind of space, i.e: "tspace:rs1" "jdbm:rs1". If you choose to use a jdbmspace running on different JVMs running in the same physical node, you need to use different storage files.
(2) The replicated space registers itself with the given uri, (i.e: rspace:rspace so you can use the Space-Factoryto locate it within your application.
(3) This is the JGroups group name. Different ReplicatedSpaces should use different group names. In addi-tion, if you use the jPOS-HA service, you want to use a different group name too.
(4) JGroups configuration. The file cfg/jgroups.xmluses JGroups' 2.2.8 default.xml configuration.
(5) If true, the ReplicatedSpace will output useful debugging information to the Logger.
6.5.2. Implementation notes
The ReplicatedSpace uses group communications among multiple nodes. It sends requests defined in an inner class ReplicatedSpace.Request.
As of this writting, it uses the following 4 message types:
Table 6.1. Message types
Operation Description
OUT When you callrs.out(key, data), a Request.OUTis sent to all members. The request carries the key for that entry, its data, a timeout, and also a unique identi-fier for the entry called the reference key (refkeyfor short).
The receiving nodes will store the value and timeout using the reference key, and a pointer to it using the actual key. (see ReplicatedSpace.Ref inner class).
MOVE_REQUEST When a node wants toinpand entry, it creates a unique [local] reference key and sends aMOVE_REQUESTmessage to the coordinator.
The coordinator verifies its local space in order to double-check that the given ref was not taken by another node recently. The procedure involves keeping a local revocation cache [which defaults to 5 minutes]).
This is a unicast message sent from the node requesting the entry to the coordinat-or.
Experimental
Operation Description
MOVE_DENIED If the coordinator doesn't have the requested entry or a revocation is found in its cache, a unicastMOVE_DENIEDis sent to the requesting node.
MOVE If the coordinator finds that the entry is suitable to be taken by a node (available in the local space and not present in the revocation cache) it will inmediately broadcast aMOVErequest to all nodes.
The entry will be available in all nodes under the requested reference key, but un-linked from its former key during one minute. After that short period of time, it will expire.
The requesting node will be waiting for that particular reference key and will take it in order to use it as the return object for its inpoperation.
This prototype implementation is work in progress and it has a number of known limitations:
• If the cluster is broken and we get to have more than one coordinator, it is possible for two nodes to take the same entry using the inpoperation.
• For performance reasons the OUT operation doesn't go throw the coordinator, so it is possible for two nodes to have entries for a given key in different order.
Going throw the coordinator is an easy task (see MOVE_REQUEST implementation) and we can easily make this optional through a configuration parameter.
• If a new node joins the the cluster, old entries won't be available. We plan to solve this by adding a Re-quest.SENDMEkind of message.
• When multiple nodes are waiting for the same key and a new entry under that key arrives, all of them will compete to get it and although only one will succeed, the procedure is far from optimal. We need to devise an algorithm where the sender could attempt a unicast based distribution, probably combined with the pro-posedRequest.SENDMEmessage.
Given these limitations, we still find that the current implementation can be very useful to create ad-hoc distrib-uted applications. For example, it is very easy to have a ChannelAdaptor operate over a ReplicatedSpace, or have multiple TransactionManagers pull work off a ReplicatedSpace.
Tip
We strongly recommend using the ReplicatedSpace in an environment where all entries are volatile and have a short duration (in the couple of minutes range). If the application doesn't expect to have long lasting entries, a broken/merged cluster will self-heal in a short period of time.
As a side effect of the way we've choosen to implement the ReplicatedSpace using an underlying local space, one can have access to that local space and pull entries directly from it (by calling its inp operation). That means that a node can outentries on the replicated space and more than one node can inp them if it uses a ref-erence to the local space instead of a refref-erence to the replicated one.
Note
We are using JGroups' default configuration, but we there's a lot to experiment in that area by using different protocol stacks according to the user's requirements, cluster topology, etc.
Experimental