QMUX startService method query

[Geoff Chiang]

I was just messing around with stopping and starting a QMUX using the
stop() and start() QBean methods and found that after calling start()
after it had been stopped, the MUX was unable to read from the space.

The reason appears to be because of QMUX's implementation of
startService(). The implementation has the following guard:

if (getState() == STOPPED) {
...
}

When startService() is called from the start() method in QBeanSupport,
the state is set to STARTING a couple of lines before the
startService() template method is invoked. This means that in this
circumstance, the guard condition never evaluates to true.

Is it correct to say that the QBeanSupport startService() method is
only called from the start() method in the same class? I know the
startService() method is public, but I can't see anywhere else in the
framework that invokes it.

Does it make sense to modify this guard clause to: "if (getState() ==
STOPPED || getState() == STARTING)"?


Geoff

[Alejandro Revilla]

Hi Geoff,

I believe I've fixed this here:

https://github.com/jpos/jPOS/commit/13cddcc932d8ced2db835bba77e9f13c96e1454f

Can you give it a try at your convenience?

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage.
Please support jPOS, contact: sa...@jpos.org

You received this message because you are subscribed to the  "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users

[Geoff Chiang]

Hi Alejandro,

I will try this when I have a spare few minutes.

Looking at the diff, you might want to consider adding another
"listenerRegistered = true" line when the listener is reattached in
the startService() method. I think it will work without it (because
the listenerRegistered field will still be false if you subsequently
stop/start again), but for the sake of correctness, the field probably
should reflect the QMUX's current listening state at all times.

Geoff

On Nov 17, 12:14 pm, Alejandro Revilla <a...@jpos.org> wrote:
> Hi Geoff,
>
> I believe I've fixed this here:
>

> https://github.com/jpos/jPOS/commit/13cddcc932d8ced2db835bba77e9f13c9...

>
> Can you give it a try at your convenience?
>

> > Please seehttp://jpos.org/wiki/JPOS_Mailing_List_Readme_first

> > To post to this group, send email to jpos-...@googlegroups.com

> > To unsubscribe, send email to jpos-users+...@googlegroups.com<jpos-users%2Bunsu...@googlegroups.com>

[Alejandro Revilla]

Good point, fixing it right away. Thank you!

Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first

To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com

[Geoff Chiang]

Hi Alejandro,

I took another look at this code change and I wonder whether it could
be simplified. The lifecycle methods in QMUX would be more
"symmetrical" if the initService() and destroyService() methods were
given the responsibility of registering and unregistering the QMUX
with the NameRegistrar, while the startService() and stopService()
methods were given the responsibility of adding and removing the QMUX
as a SpaceListener from the LocalSpace. This would also dispense with
the need for the "listenerRegistered" field (with a caveat that I will
discuss below).

So the code would look like this (this won't come out right in the
browser, but hopefully you can see what I'm saying):

public void initService() throws ConfigurationException {
...
// remove the sp.addListener (in, this) line from here
NameRegistrar.register("mux." + getName(), this);
}

public void startService() {
sp.addListener(in, this);
}

public void stopService() {
sp.removeListener(in, this);
}

public void destroyService() {
NameRegistrar.unregister("mux." + getName());
}

This symmetry makes sense to me, since starting and stopping the MUX
will make it start and stop responding to ISOMsgs in the TSpace,
without affecting anything in the NameRegistrar.

Of course, getting rid of the "listenerRegistered" field only works if
the QBean start() method is not going to be called while the QBean is
STARTED, otherwise it will register the SpaceListener twice (or as
many times as the startService() method is invoked). The QBeanSupport
start() method only protects against the method being invoked while
the QBean is in DESTROYED, STOPPED or FAILED states. So currently, it
is possible for startService() to be invoked while the QBean is in
STARTING or STARTED states. Is there any reason for this? It also
makes sense to me that the start() service do nothing if invoked in
the STARTING or STARTED states.

Geoff

On Nov 18, 8:52 am, Alejandro Revilla <a...@jpos.org> wrote:
> Good point, fixing it right away. Thank you!
>

> > <jpos-users%2Bunsu...@googlegroups.com<jpos-users%252Buns...@googlegroups.com>

[Alejandro Revilla]

Geoff,

I believe this is a very reasonable change.

I've created an issue (https://jpos.org/issues/issue/jPOS-40) and will try to work on it a-s-a-p.

[Alejandro Revilla]

FYI, fixed jPOS-40, I hope you agree with my comments regarding the listenerRegistered flag.