Channel Pooling, a better way?

69 views
Skip to first unread message

JTO

unread,
Mar 5, 2008, 9:14:33 AM3/5/08
to jPOS Users
I am currently working through some implementation scenarios and have
a solution that is functional, but I am just not sure that it is the
'best' way to achieve my intended outcome.

I have 8 incoming connections from a single processor (different IPs
&
ports) and I have created a front-end node cfg file for each one.
These all point to my TXN MGR which pre-processes the message to
standardize and then route to the appropriate MUX/Channel. My goal is
to have one MUX for each system and have all eight incoming
connections then route those messages in a round robin fashion to the
eight backend connections.


Basically this is where I started (no jPos at all)


IP x.x.x.x:yyyy ---------- IP a.a.a.a:bbbb
IP x.x.x.x:yyyy ---------- IP a.a.a.a:bbbb
IP x.x.x.x:yyyy ---------- IP a.a.a.a:bbbb
IP x.x.x.x:yyyy ---------- IP a.a.a.a:bbbb
....

Inserting jPos into the middle to re-route to a new and the old
backend system based on msg data.


IP x.x.x.x:yyyy -----|----- IP a.a.a.a:bbbb
|----- IP s.s.s.s:tttt
IP x.x.x.x:yyyy -----|----- IP a.a.a.a:bbbb
|----- IP s.s.s.s:tttt
IP x.x.x.x:yyyy - jPos - IP a.a.a.a:bbbb
|----- IP s.s.s.s:tttt
IP x.x.x.x:yyyy -----|----- IP a.a.a.a:bbbb
|----- IP s.s.s.s:tttt ....


In order to accomplish this I used information found at
http://article.gmane.org/gmane.comp.java.jpos.devel/1446 to create a
Spacelet. I modified the SpaceLet example to round robin the
connections like this.


<spacelet name="pooledchannels">
<space>tspace:default</space>
<run>
int lastChannel = 1;
while (spacelet.running()) {
Object obj = sp.rd ("MUX.send", 3000);
if (obj != null) {
if (sp.rdp ("CHANNEL.550"+lastChannel+".ready") != null)
{
sp.out ("CHANNEL.550"+lastChannel+".send",
sp.in("MUX.send"));
}
lastChannel++;
if (lastChannel >8)
lastChannel=1;
}
}
</run>
</spacelet>


It works perfectly in that whenever an incoming TXN is routed to
system A, each BE node is used in a round robin fashion.


Is this the best way to accomplish this? I reviewed MUXPool and
ChannelPool but I could not figure out how to have it work in this
manner.

Alejandro Revilla

unread,
Mar 5, 2008, 9:42:42 AM3/5/08
to jpos-...@googlegroups.com
>
> In order to accomplish this I used information found at
> http://article.gmane.org/gmane.comp.java.jpos.devel/1446 to create a
> Spacelet. I modified the SpaceLet example to round robin the
> connections like this.
>
> <spacelet name="pooledchannels">
> <space>tspace:default</space>
> <run>
> int lastChannel = 1;
> while (spacelet.running()) {
> Object obj = sp.rd ("MUX.send", 3000);
> if (obj != null) {
> if (sp.rdp ("CHANNEL.550"+lastChannel+".ready") != null)
> {
> sp.out ("CHANNEL.550"+lastChannel+".send",
> sp.in("MUX.send"));
> }
> lastChannel++;
> if (lastChannel >8)
> lastChannel=1;
> }
> }
> </run>
> </spacelet>
>
Cute!

>
> It works perfectly in that whenever an incoming TXN is routed to
> system A, each BE node is used in a round robin fashion.
>
> Is this the best way to accomplish this? I reviewed MUXPool and
> ChannelPool but I could not figure out how to have it work in this
> manner.
>

If it's working, don't fix it.. :) - if you need more performance, you
can consider moving your SpaceLet code to a SpaceInterceptor (basically
same concept, but you compile your run method in Java).

BTW, I think we could make that very easy for you if we modify the
SpaceLet implementation so that 'run' could accept an optional 'class'
argument where you can pass a Runnable and optionally Configurable
object, i.e:

<run class="your.company.YourRunnable" />

Anyway, I wonder why you couldn't do that with a MUXPool, I'm probably
not understanding your use case here, can you clarify?

JTO

unread,
Mar 6, 2008, 11:30:38 AM3/6/08
to jPOS Users
Alejandro,

I initially wanted to use MUXPool, however since I have multiple
connections into my TXNMgr I have to send to a specific MuxPool in
order to accomplish the type of routing that I am attempting.

Here is what I am trying to accomplish:

Numerous incoming FE channels (8 for now) that get preprocessed with
my TXNMGR and then based on merchant/card # are routed to one of two
Muxes.

The first Mux goes to our legacy system, which has an existing 8583
switch in place (with 8 ports). These 8 ports are connected on the
other end to multiple nodes which connect to our legacy backend
application.

The second Mux is connecting to our new (pre-production) backend
application (1 node).

If the merchant and card do not match (new system route), then the TXN
is just passed through to the old system. The old system is load
based (ie port 1 is used until busy, then 1&2, then 1&2&3,etc...). To
even things out I wanted to round-robin the TXNs into the old system
(balance our own load).

With all that said, I think I could setup 8 FE's,1 TXNMgr, 8 Muxes, 8
BE's. Trying to minimize the number of config files for our support
folks I think it is easier to understand the 8 physical incoming ports
and the 8 physical outgoing ports being controlled by one TXNMgr and
one Mux.

Maybe I am trying to oversimplify but when we go into true production
the number of nodes will be significant (60 times). This would leave
me with a config folder that has a few hundred files in it.

I hope this helps explain....

-John

Alejandro Revilla

unread,
Mar 6, 2008, 11:56:09 AM3/6/08
to jpos-...@googlegroups.com
>
> I hope this helps explain....
>
Makes sense and I believe your SpaceLet based solution is very elegant.

Once you have everything ironed out you may just want to have a 'run'
method written in Java. This could be as easy as starting a new Runnable
from the <run>...</run> script and passing it appropriate parameters.

In that case, the BSH overhead would just happen once at startup.

--Alejandro

Reply all
Reply to author
Forward
0 new messages