Skip to main content

jPOS 1.8.9 templates

· One min read
Alejandro Revilla
jPOS project founder

In jPOS 1.8.8 we had a nice Maven Archetype that got lost in our move to Gradle. As a replacement, in 1.8.9 we have a lightweight [https://github.com/jpos/jPOS-template](jPOS template) project that you can fork or download. Just rename with your own project name and you are ready to go. The following commands will create you a sample Eclipse project:

git clone git://github.com/jpos/jPOS-template.git mv jPOS-template myproject cd myproject ./gradlew eclipse

In order to run jPOS, you can:

./gradlew installApp cd build/install/myproject bin/q2

You can create your own source files in src/main/java and resources in src/main/resources. The directory structure is pretty much the standard Maven one.

./gradlew tasks

Is your friend. UPDATE: Changed installApp task to use standard build/install instead of runtime directory.

jPOS 1.8.8 has been released

· One min read
Alejandro Revilla
jPOS project founder

jPOS 1.8.8 has been released (download, ChangeLog). We are moving development to 1.8.9 where we'll switch the build system from Maven to Gradle. You will still be able to fetch jPOS using Maven as we'll produce compatible artifacts, so nothing changes for end users, unless you're building jPOS from sources.

The Peter Effect

· 3 min read
Alejandro Revilla
jPOS project founder

/by apr/ When I was a child I used to spend a lot of time with my grand parents.

A neighbor of them had a radio/tv repair shop, his name was Peter (obviously locally pronounced Peh-tehr), for me, he was a genius.

A family with probably twice the IQ of the rest of the neighborhood together (I remember Peter's father playing chess all the time, against himself using a large mirror), and Peter always repairing stuff, you entered the place and enjoyed that very special solder smell that I still like.

Peter was a man of very few words, he knew me since I was born, but he'd never talked to me like a child, he was very serious, yet had a sarcastic sense of humor, the kind of humor smart people have. Later, when I was probably 10 or 12, a couple very good friends and an awesome game introduced me to electronics.

After finishing several small projects on the wooden board, and burning several AF-116s and AC-126s transistors, I was ready for a larger project, a six-transistor AM radio receiver. I was very anxious, so I started soldering some components, but then I ran out of solder, probably over the weekend where I couldn't buy more. That wasn't going to stop me, so I continued mixing cables together without soldering, and using GLUE (yes, glue, I'm embarrased to say that, but I was a child, and an anxious one, I "needed" that radio receiver running!).

The moment came where I had to apply voltage and test, but of course, the thing wouldn't work. Several tests here and there, the whole thing was wrong, half baked, short circuits everywhere, transistors probably over-heated and melted by my inhability to properly use the soldering gun, everything was a mess. Then I had a brilliant idea: Peter! I waited until Monday, headed to my grand parent's and onto Peter's.

I handed him the project and said, very seriously: "Can you repair this? it suddenly stopped working". I still remember Peter's reaction, he laughed, yelled, laughed, then yelled again, THIS THING HAS NEVER WORKED!! (probably thinking what a little liar son of a b....!).

You may wonder why I'm telling you this story and here is the answer: In jPOS Consulting, we receive "for repair" things that never worked and customers claim they are broken.

We get blasted by walls of code that never ever worked, they are flawed by design, and customers ask us to fix them. It would be much much easier and cheaper to engage us earlier in the project definition and development than wasting their time creating code that's impossible to fix.

When we receive code like that, we call it The Peter Effect.

PS.- I wanted to write this post a long time ago, because this is a recurring problem we have here, and wanted to read it to my friend Peter. Unfortunately, I was busy to do it, and he recently passed away. I really miss him, we exchanged very few words because he didn't like to talk a lot, but I knew he appreciated my interest in electronics, and I've always respected him a lot. If you asked me what I wanted to be when I was a child, I didn't want to go to the moon or be a policeman or a fireman, I probably wanted to run a repair shop like Peter's.

jPOS-EE SysConfigConfigurationFactory

· One min read
Alejandro Revilla
jPOS project founder

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

TransactionManager Debug and Trace events

· 2 min read
Alejandro Revilla
jPOS project founder

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.

jPOS Maven Archetype

· One min read
Alejandro Revilla
jPOS project founder

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'

jPOS Performance

· 3 min read
Alejandro Revilla
jPOS project founder

First Data NOC 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.

jPOS 1.8 series

· One min read
Alejandro Revilla
jPOS project founder

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