jPOS 1.8.6 is out, we've moved development to 1.8.7. You can get it at the download page.

jPOS-EE sysconfig module has a new SysConfigConfigurationFactory class that can be used to pull configuration properties from the sysconfig table instead of the XML configuration file (see jPOS-79). By adding the attribute configuration-factory="org.jpos.ee.SysConfigConfigurationFactory" to any QBean element, one can then set properties using the 'sysconfig:' prefix and the property's id in the database, i.e.:

Here is an example:

clientsimulator-send clientsimulator-receive 10000

While working on a project, from time to time, we might request the TransactionManager 'Debug' and 'Trace' events.

The Debug event is the one created by the org.jpos.transaction.Debug participant and looks like this:

    JCARD
      100.55
      org.jpos.iso.channel.CSChannel@71e13a2c
      open \[0.6/0.6\]
         prepare-response \[6.0/6.6\]
         close \[1.0/7.6\]
         end \[15.3/15.3\] 
      Sun Feb 12 22:47:39 UYST 2012
      txnmgr
      org.jpos.ee.DB@7a315068
      100.55 (notsupported prepareresponse close sendresponse)
      invalid.request
      Unsupported transaction
      ...
      ...

It basically dumps the Context. On the other hand, the Trace event usually comes after the Debug (provided the TransactionManager's trace property is set to true) and looks like this:

 txnmgr-1:2
            prepare: org.jpos.jcard.PrepareContext NO_JOIN
            prepare: org.jpos.jcard.CheckVersion READONLY NO_JOIN
            prepare: org.jpos.transaction.Open READONLY NO_JOIN
            prepare: org.jpos.jcard.Switch READONLY NO_JOIN
      groupSelector: notsupported prepareresponse close sendresponse
            prepare: org.jpos.jcard.NotSupported NO_JOIN
            prepare: org.jpos.jcard.PrepareResponse NO_JOIN
            prepare: org.jpos.transaction.Close READONLY
            prepare: org.jpos.jcard.SendResponse READONLY
            prepare: org.jpos.jcard.ProtectDebugInfo READONLY
            prepare: org.jpos.transaction.Debug READONLY
             commit: org.jpos.transaction.Close
             commit: org.jpos.jcard.SendResponse
             commit: org.jpos.jcard.ProtectDebugInfo
             commit: org.jpos.transaction.Debug
    head=3, tail=3, outstanding=0, active-sessions=2/2, tps=0, peak=0, avg=0.00, elapsed=22ms
    prepare: org.jpos.jcard.PrepareContext \[0.0/0.0\]
      prepare: org.jpos.jcard.CheckVersion \[0.0/0.0\]
      prepare: org.jpos.transaction.Open \[0.5/0.6\]
      prepare: org.jpos.jcard.Switch \[0.0/0.6\]
      prepare: org.jpos.jcard.NotSupported \[0.1/0.7\]
      prepare: org.jpos.jcard.PrepareResponse \[5.8/6.6\]
      prepare: org.jpos.transaction.Close \[0.0/6.6\]
      prepare: org.jpos.jcard.SendResponse \[0.0/6.6\]
      prepare: org.jpos.jcard.ProtectDebugInfo \[0.0/6.7\]
      prepare: org.jpos.transaction.Debug \[0.0/6.7\]
       commit: org.jpos.transaction.Close \[1.0/7.7\]
       commit: org.jpos.jcard.SendResponse \[4.3/12.0\]
       commit: org.jpos.jcard.ProtectDebugInfo \[0.2/12.3\]
       commit: org.jpos.transaction.Debug \[9.3/21.7\]
      end \[22.8/22.8\]

UPDATE - in recent versions of jPOS, the Debug and Trace events are placed together by the TransactionManager.

If you use Maven, there's an extremely easy way to create a jPOS application now:

mvn archetype:generate
-DarchetypeGroupId=org.jpos
-DarchetypeArtifactId=jpos-archetype
-DarchetypeVersion=1.8.2
-DarchetypeRepository=http://jpos.org/maven

If you don't want to use the remote archetype, you can always 'mvn install' jPOS source code and then:

mvn archetype:generate -DarchetypeCatalog=local

UPDATED to use 1.8.2 instead of 1.8.1-SNAPSHOT UPDATED to use 'archetypeRepository' instead of 'DremoteRepositories'

When companies -- specially start-ups -- ask us regarding jPOS performance, they usually tell us they need to support a massive load in the 1000+ TPS range. In order to give some perspective to these requirements, we always exchange some industry information with jPOS power developer Andy whose company manage some jPOS systems reaching 200M transactions per month, and today Andy sent me a very nice link (via OLS' Ron Barker) about one of the largest acquirers in the world, during a really busy day, requiring 988 TPS, the important part: "The record day on Nov. 26 translated to about 988 payment authorizations per second." So I thought it would be nice to start having some stable performance tests here and there in jPOS, so we can have something to measure where we are now, and even if it's really fast for most applications, attempt to improve it. Because many developers use jPOS just to pack and unpack ISO-8583 messages, I thought it would be nice to start by measuring where we are now in the pack/unpack department. I believe there's plenty of room for optimization, but I hope you'll agree that we are in pretty good shape. I've just added a performance test to PackagerTestCase.java to try:

• 100000 pack operations
• 100000 unpack operations
• 100000 pack/unpack operations
• 100000 update, pack, and unpack operations

and here are the results:

PACK tps=31531, peak=31531, avg=25156.00 [3779.2/3779.2] UNPACK tps=32371, peak=37026, avg=29081.00 [3047.9/6827.2] PACK/UNPACK tps=16605, peak=16634, avg=16144.25 [6254.2/13081.5] UPDATE/PACK/UNPACK tps=10862, peak=10862, avg=10815.16 [10430.9/23512.5] end [23512.6/23512.6]

We are operating with a pretty heavy message, way bigger than a real-life ISO-8583 message:

The last test is the more realistic one, because we tweak the message by changing some fields (i.e. 7,11,12,13), then pack and unpack. In most jPOS applications, we receive a message, change a few fields, and send it back, for instance, a typical server will reply by just changing a few fields (i.e. 39, 38) and eventually resetting a few others. I think there's tremendous room for optimization by caching the binary image of the packed message at the field level, avoiding a re-pack unless the field has changed. Now that we know where we are, I hope to start testing some optimizations soon. You're encourage to do so too. BTW, these figures were taken on an MBP, it would be nice to have some feedback from runs on larger servers.

Starting in jPOS 1.8, we are going to manage jPOS builds using Maven. There's a mvn branch soon to be merged with master. It seems 1.7.2 will be the last version of the old series managed by 'ant', will jump to 1.8.0 soon. You can try 1.8.2 by adding to your pom.xml:

jpos jPOS Central Repository http://jpos.org/maven default

org.jpos jpos 1.8.2

1.7.2 has already been committed to jPOS EE. We'll continue with the old module-based build system on jPOS-EE for a while. UPDATE: changed 1.8-SNAPSHOT to 1.8.0 UPDATE: changed 1.8-SNAPSHOT to 1.8.2

Quick note to let you know that as of subversion r3019, new jPOS development will take place in github.com/jpos. The jPOS Project Guide has been updated.

/by apr/ I've spent a great time listening to great talks at RubyConf Uruguay organized by Cubox. Now I totally understand when they say "Old School Teamwork Fun People, Serious pros: The mix you’re looking for" in their website. It is exactly that. I was delighted to listen to Charles Nutter (JRuby's author) talk but was sad with this tweet from him a few hours ago: So I tried latest JRuby on latest jPOS, it took just a few minutes. I've added an optional 'jruby' module to jPOS-EE (just depends on the 'commons' module) and you can now deploy a QBean that looks like this:

puts "Hello jRuby!"

And that's all there is to it :) If you want to try this in a new small project, you can follow the HOWTO in jPOS Project Guide around page 35, just add the 'commons' and 'jruby' module as svn:externals, and you'd be ready to go. And the output, you guess it: Hello jRuby! Mr. Nutter, Welcome to this southern Montevideo and beware with the dogs here :)

Inspired by this talk, I got reminded to play with EAVs in jPOS-EE. I've created a jPOS-EE modules called "things" that I believe it's a good thing to have in most applications. I don't think this is a one-size-fits-all solution, you probably don't want to store your core tables (such as the transaction log, miniGL stuff, whatever) using this open schema approach, but for everything else, having this open schema can save your day (in the same way a 'flags' field in most tables can help at some point). Using it is very simple, you create a "thing" using the ThingsManager:

DB db = new DB();
ThingsManager mgr = new ThingsManager(db); Thing t = mgr.create("MyThing");

Then you can put Strings, Longs, Dates, Timestamps, long Strings and BigDecimals to your thing, i.e:

t.put ("AString", "This is a string"); t.put ("ALong", Long.MAX_VALUE); t.put ("MyInteger", i); t.put ("Date", d); t.put ("Timestamp", new Timestamp(now)); t.put ("BigDecimal", ONE_THOUSAND); t.putText("Text", "The quick brown fox is brown and the dog is lazy, and jumps.");

The ThingsManager has some handy methods already, and we'll add more as the need arise.

public List getAll (String type) ; public Thing getLast (String type); public List listByStringName (String type, String name); public List listByStringValue (String type, String value); public List listByStringNameValue (String type, String name,String value); public List listByTextName (String type, String name); public List listByTextValue (String type, String value); ... ...

Some immediate use comes to mind, we could use this to provide a more type-safe, versionable version of our existing SysConfig table (i.e. we could have a thing called 'SysConfig' and keep previous versions as 'SysConfig;1', 'SysConfig;2', etc. (or another numbering scheme if you find this one too VMS-eske). It's also good to handle extremely proprietary stuff such as fee configuration, currency exchange, etc. found in many jPOS applications. The things module is available in jPOS-EE as of r307

In jCard and jPTS we use the concept of Stations, we have Source Stations (SS), Destination Stations (DS), Monitoring Stations (MS), Control Stations (CS) and Cryptographic Stations (HSMS), etc. Every station usually requires a handful Q2 services (QBeans), such as a MUX or MUXPool, one or more ChannelAdaptors with their filters, LogonManager, KeyExchangeManagers, eventually an independent logger, etc. You can configure those manually for a small set of stations, you can also use some scripts, but in order to support a large number of stations, and to easily manage them from the UI, we use a database to keep their basic configuration (station type, host, port, timeouts, etc.) and then use these new transient services provided by Q2. When Q2 starts, it's create an unique transient UUID, that FYI is displayed by the SystemMonitor task:

jPOS 1.6.9 r2950 e424833b-c2c1-4f8b-b743-8a69271912a2 00:00:00.170 ... ...

When you deploy a QBean using Q2's deployElement method (which is now public), you can flag that qbean as 'transient' (there's a boolean parameter). In that case, Q2 will remove the file on exit, but just in case the system crashes, it also adds a 'transient' attribute to the QBean, i.e:

... ...

The next time it runs, Q2 will generate a new instance ID, so in the rare situation where an old deployment descriptor is present in the deploy directory, it will be ignored and deleted (as it should have been removed at the previous exit). Q2.deployElement is a handy method that requires a JDom Element. If you are not a member of the JDom church, you can always create your QBean manually, you can get to know Q2's instance ID by calling its getInstanceId() method that gives you an UUID,. Note: when you deploy a bundle using Q2 --config=/path/to/your/bundle, Q2 now flags the exploded descriptors as transient. This is available as of jPOS 1.6.9 r2950