Regarding Network Messages ( Login/Logoff/Echo )

[Matthew C]

I posted a message earlier, and I cannot find an option to respond to
it correctly, so I will simply ask again.


I have a need to have my network manager ( Handling logon messages and
whatnot ) send a particular message in the case when the cahnnel is
shut down on purpose.

So, if I remove 10.cahnnel.xml in order to take it down to say test
outage or error messages on my client code, I need to send a network
message to the host alerting them that it is an intended shutdown,
before the file is un-deployed.


Does that make sense?

Previously this was in a single Java file, handling creating new
ISOServer, ISOMux, etc... with the line
Runtime.getRuntime().addShutdownHook( new ClientProgram() );

But I want to move to the config file approace with Q2, and have this
program be the request listener on the various services.


I was hoping that there was some message that gets sent before the
config fiel is un-deployed, and the disconnect happens.

Thanks for your time.

[Alejandro Revilla]

You can extend the ChannelAdaptor and override the stopService method. There you can create a 0800 message and send it to the Space queue, then call super.stopService().

Ideally, your ChannelAdaptor implementation could implement XmlConfiguration, so you could pull the message to be sent from the XML configuration itself (i.e. a <stop> element that could have an inner <isomsg>).

[Matthew C]

Thanks, I hadn't looked into the channels for this, but looking in
now,

It appears that BaseChannel is also Observable, so if I needed to, I
could set my manager up to pullthis particualr channel out of the
NameRegistrar and observe it.

Checking for when it gets set to unusable, but before the
closeSocket. THe only public method that it appears I could use is
isConnected(), but I imigine I would be checking in my manager
code,
if( obj.isConnected() == false() ){
if ( previous_IsConnectedValue_FromLast_Notify_Call =connected){
yaddayadda;
}
}

If the channel is really unusable, it wont go through, but if its in
the disconnect phase it will.

Does it seem appropriate to use the socket at this time?

Thanks for your time.

On Oct 21, 3:07 pm, Alejandro Revilla <a...@jpos.org> wrote:
> You can extend the ChannelAdaptor and override the stopService method. There
> you can create a 0800 message and send it to the Space queue, then call
> super.stopService().
>
> Ideally, your ChannelAdaptor implementation could implement
> XmlConfiguration, so you could pull the message to be sent from the XML
> configuration itself (i.e. a <stop> element that could have an inner
> <isomsg>).
>

[Alejandro Revilla]

I would go for my original suggestion, I believe it's more clean and doesn't assume that the channel actually has to extend BaseChannel.

You could add a couple of tags to the ChannelAdaptor configuration, i.e:

 <on-connect>
    <isomsg>
      <field id="0" value="0800" />
      <field id="11" value="$trace" /> <!-- you can use MacroFilter or BSHFilter to place a value here -->
      ...
      ...
 </on-connectt>

Same goes for 'on-shutdown', and we could even add an on-idle.

I'm booked for the day, but I believe I can add that functionality to ChannelAdaptor itself so you don't have to extend it.

Would that work for you?

[Matthew C]

One of my problems is that I won't have time to re-deploy the core
libraries, and get the required reviews that I would need.
So it sounds like a good idea, but I have to use new classes that can
get reviewed in time and not be part of an existing jar file.

So I will probably extend either the channel or the channeladaptor,
since the stopService calls the channels sdisconnect function, and set
thet in the deploy/lib directoy.



Thanks for your input.

On Oct 21, 3:55 pm, Alejandro Revilla <a...@jpos.org> wrote:
> I would go for my original suggestion, I believe it's more clean and doesn't
> assume that the channel actually has to extend BaseChannel.
>
> You could add a couple of tags to the ChannelAdaptor configuration, i.e:
>
> <on-connect>
> <isomsg>
> <field id="0" value="0800" />
> <field id="11" value="$trace" /> <!-- you can use MacroFilter or
> BSHFilter to place a value here -->
> ...
> ...
> </on-connectt>
>
> Same goes for 'on-shutdown', and we could even add an on-idle.
>
> I'm booked for the day, but I believe I can add that functionality to
> ChannelAdaptor itself so you don't have to extend it.
>
> Would that work for you?
>

[Alejandro Revilla]

You can certainly do that. Just curious, which jPOS revision are you using? (see bin/q2 --version).

[Matthew C]

It is the 1.6.3/4 SVN

I'm at home now, so if there is something more specific, I can't pull
it up.

On Oct 21, 6:10 pm, Alejandro Revilla <a...@jpos.org> wrote:
> You can certainly do that. Just curious, which jPOS revision are you using?
> (see bin/q2 --version).
>

[Matthew C]

The program I am modifying was using 1.4.8, if you are interested.

[demsey]

Hi Alejandro
I have done quite similar implementation that you said.
I use XmlConfiguration with bsh for configure logon, echo and logoff
messages.
In addition is some configuration parameter for set inactivity time to
sent echo message.
Difference is in that I send message to mux but from some time i thing
for change it to space;)

I can send you my MonitoredChannelAdaptor implemetation for recheck
and refactoring some names (and even include for jpos ChannelAdaptor).
For me it work very well in productions environments and i can share
it for community;)

cheers

On 21 Paź, 22:07, Alejandro Revilla <a...@jpos.org> wrote:
> You can extend the ChannelAdaptor and override the stopService method. There
> you can create a 0800 message and send it to the Space queue, then call
> super.stopService().
>
> Ideally, your ChannelAdaptor implementation could implement
> XmlConfiguration, so you could pull the message to be sent from the XML
> configuration itself (i.e. a <stop> element that could have an inner
> <isomsg>).
>

[Alejandro Revilla]

Hey Demsey,

Going to the MUX is good, but we have some situations where we have multiple channels assigned to the same MUX (i.e. two active connections to two different data-centers, and we need to send logon and echo test messages over both channels.

There's an 'incoming' directory in the jPOS repository where you can place that code, or share it in the file area of this group.

--Alejandro

[Alejandro Revilla]

As a follow-up to my previous e-mail, and after playing around with the idea of implementing a ConnectionListener, I now recall that due to the reasons expressed in my previous post (mux with more than one channel), we've implemented the MUXPool, so we still do the logon/logoff/echotest at the individual MUX level, while the higher level application uses the MUX pool.

So Demsey, I believe your approach is the way to go.

[AAO]

I've got some posts in my blog related to the MUX pool (why and how to implement) If anyone is interested, I'll pass along the links.

Andy Orrock
mobile - 972.679.9464

---

From: Alejandro Revilla <a...@jpos.org>

Date: Sat, 24 Oct 2009 19:06:16 -0200

To: <jpos-...@googlegroups.com>

Subject: [jpos-users] Re: Regarding Network Messages ( Login/Logoff/Echo )