Base24Channel - org.jpos.iso.ISOException: 34 consumed=4

pushpa

unread,

Jan 27, 2011, 7:34:19 AM1/27/11

to jPOS Users

Hi,

Client and server side code uses Base24Channel and Genericpackager.
When client sends data to server, server generates ISOException.

Server:

<log realm="channel/127.0.0.1:2941" at="Thu Jan 27 17:52:48 GMT+05:30
2011.722" lifespan="1093ms">
<receive>
<iso-exception>
34 consumed=4
org.jpos.iso.ISOException: 34 consumed=4
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
279)
at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:416)
at org.jpos.iso.BaseChannel.unpack(BaseChannel.java:903)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:671)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:130)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:
71)
</iso-exception>
--- data ---
0000 30 31 30 30 43 30 30 30 30 30 30 30 30 30 30 30
0100C00000000000
0010 30 30 30 30 31 32 31 32 33 34 35 36 37 38 39 31
0000121234567891
0020 31 32 12

</receive>
</log>

Data received by server looks different from data sent by client.

Client:
<log realm="test-channel/127.0.0.1:8000" at="Thu Jan 27 17:52:48 GMT
+05:30 2011.722" lifespan="15ms">
<send>
<isomsg direction="outgoing">

<field id="0" value="0100"/>
<field id="1" value="4000000000000000"/>
<field id="2" value="123456789112"/>
</isomsg>
</send>
</log>
<log realm="test-channel/127.0.0.1:8000" at="Thu Jan 27 17:52:48 GMT
+05:30 2011.800" lifespan="78ms">
<receive>
<peer-disconnect/>
</receive>
</log>
Jan 27, 2011 5:52:48 PM test1.UI sendMsgActionPerformed
SEVERE: null
java.io.EOFException: connection closed
at
org.jpos.iso.channel.BASE24Channel.streamReceive(BASE24Channel.java:
104)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:651)
etc...

Chhil

unread,

Jan 27, 2011, 8:40:23 AM1/27/11

to jpos-...@googlegroups.com, jPOS Users

Is the MCW_AuthorizationRequest_Package.XML identical on both sides as that's what the generic packager seems to be using?

-Chhil

On 27-Jan-2011, at 6:04 PM, pushpa <pushpat...@gmail.com> wrote:

MCW_AuthorizationRequest_Package.xml

pushpa A

unread,

Jan 28, 2011, 10:11:17 AM1/28/11

to jpos-...@googlegroups.com

yes, MCW_AuthorizationRequest_Package.XML file is common for both
server & client.

Thanks
Pushpa

Mark Salter

unread,

Jan 28, 2011, 10:47:56 AM1/28/11

to jpos-...@googlegroups.com

On 28/01/2011 15:11, pushpa A wrote:
> yes, MCW_AuthorizationRequest_Package.XML file is common for both
> server & client.

But is it the same file or a complete and *identical* copy?

Please reread my previous responses as well Pushpa, you are missing some
detail from your question(s) that could help us help you.

The Channel name and code version and the packager definition content
must precisely match at client and server.

Can you add a logger to your Channel and Packager on both client and
server and share all the output?

There is a mismatch somewhere, you just seem to need need help in
finding where.

--
Mark

pushpa

unread,

Jan 30, 2011, 11:53:12 PM1/30/11

to jPOS Users

Here goes the log after adding logger to Packager.

Server:
-----------
<log realm="GenericPackager" at="Mon Jan 31 10:13:33 GMT+05:30
2011.165">
<unpack>

30313030433030303030303030303030303030303132313233343536373839313132
<exception name="34">
java.lang.ArrayIndexOutOfBoundsException: 34
at org.jpos.iso.ISOUtil.hex2BitSet(ISOUtil.java:652)
at org.jpos.iso.IFA_BITMAP.unpack(IFA_BITMAP.java:68)
at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:
215)

at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:416)
at org.jpos.iso.BaseChannel.unpack(BaseChannel.java:903)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:671)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:130)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:
71)

</exception>
</unpack>
</log>
<log realm="channel/127.0.0.1:1447" at="Mon Jan 31 10:13:33 GMT+05:30
2011.165" lifespan="1500ms">
<receive>
<iso-exception>
34 consumed=4
org.jpos.iso.ISOException: 34 consumed=4 etc....

Client
-----------
<log realm="GenericPackager" at="Mon Jan 31 10:13:33 GMT+05:30
2011.149">
<pack>

30313030433030303030303030303030303030303132313233343536373839313132
</pack>
</log>
<log realm="test-channel/127.0.0.1:8000" at="Mon Jan 31 10:13:33 GMT
+05:30 2011.149">

Mark Salter

unread,

Jan 31, 2011, 7:05:30 AM1/31/11

to jpos-...@googlegroups.com

On 31/01/2011 04:53, pushpa wrote:
> Here goes the log after adding logger to Packager.
>

I think - rather like 'kush darji' have managed not to add the logger to
the Channel or Packager.

Before I ask you for all your code and packager config, can I check...

> Client
> -----------
> <log realm="GenericPackager" at="Mon Jan 31 10:13:33 GMT+05:30
> 2011.149">
> <pack>
>
> 30313030433030303030303030303030303030303132313233343536373839313132
> </pack>
> </log>
> <log realm="test-channel/127.0.0.1:8000" at="Mon Jan 31 10:13:33 GMT
> +05:30 2011.149">
> <send>
> <isomsg direction="outgoing">
> 
> <field id="0" value="0100"/>
> <field id="1" value="4000000000000000"/>

What is this value meant to be?

If it is the bitmap, then you don't need to set this (jPOS takes care of
it) and I think it could be causing the message out of your client to be
invalid.

> <field id="2" value="123456789112"/>
> </isomsg>
> </send>
> </log>
> <log realm="test-channel/127.0.0.1:8000" at="Mon Jan 31 10:13:33 GMT
> +05:30 2011.259" lifespan="94ms">
> <receive>
> <peer-disconnect/>
> </receive>
> </log>
>

--
Mark

pushpa

unread,

Jan 31, 2011, 7:44:14 AM1/31/11

to jPOS Users

Hi Mark,

It works now, thanks for your reply. when I removed Bitmap, requests
and responses are exchanged correctly.

regards
Pushpa

Mark Salter

unread,

Jan 31, 2011, 7:50:36 AM1/31/11

to jpos-...@googlegroups.com

On 31/01/2011 12:44, pushpa wrote:

> It works now, thanks for your reply. when I removed Bitmap, requests
> and responses are exchanged correctly.

It always worked, you were breaking it 8).

It does raise the interesting question about what is happening though...

...handcrafting the bitmap seems to be what a few people think is
needed; in some cases it causes problems, but if it is possible to
block/prevent it without disabling function for those that need it...

... probably low priority, but thanks for coming back to confirm my
guess was right.

For 'SOLVED' completeness, the bitmap arriving at the server looked
wrong to me and indicated that there were more fields present than there
really were, sending the unpack off the end of the available data.
Removing the code setting field 1 - bitmap (as it is not required) seems
to have sorted the problem.

--
Mark

Reply all

Reply to author

Forward