How to guarantee the order of commands executed dynamically ?

[Vianney DEPAUW]

Hi everyone,

I'd like to expose a situation we met recently.

The situation :

Suppose a MultiCommand composed of two unique commands :

#- MyMultiCommand :

---- FirstUniqueCommand - run into JTP

---- SecondUniqueCommand - run into JAT

Now suppose than we can send this MyMultiCommand at anytime and several times during the app's lifecycle.

The problem :

Each multicommand can be start only if the previous one is finished, otherwise it will cause some break issues.

But as you can see, the FirstUniqueCommand is running into JTP. So we can't garantee that the second MultiCommand will not be finished before the first one

In a static way (for example with only two MultiCommand), the solution would be to create another MultiCommand composed of these two MyMultiCommand which garantee that the execution is sequential.

But here the command can be sent at anytime, depending on buttons. So it must be dynamic.

We develop our own approach based on wave listeners and commands Queue. Theses commands (and WaveBeans) are added into a queue. Everytime the next command is executed, we listen the wave until its consuming. Then the next one can be send.

But maybe the JRebirth-approach could be different and can be natively integrate into the framework.

[Sebastien Bordes]

Hi Vianney,

In two words, I think that you can use WaveListener to be informed when the first MMC is achieved before triggering the second.

You should define as well MMC as sequential, (if the SUC should be performed after FUC)

I will test this tonight, and patch it if the MUC is marked as process whereas FUC is still running.

Seb

[Sebastien Bordes]

After some investigations I can conclude that in your case:

You probaly use default implementation of MultiCommand which run commands sequentially, MUC->FUC->SUC

The command will probably terminate in this order SUC-FUC-MUC

I pushed a patch but it only concerns parallel mode because it was working well for sequential. The patch also contains some tests (not run on our continuous integration server due to unavailability of real headless mode)

To avoid launching twice a command, you could create a siimple command that launches the multiCommand only if the previous one has been achieved, attach a WaveListener to the wave returned during the MultiCommand (i have update the run method that will now return the generated wave; check 7.7.1-SNAPSHOT on OJO repository).

Be careful of the way you launch your MultiCommand, it can affects its registration into the command facade, use your own keypart or retrieve method instead of calling callCommand (that induces a unique timestamped UniqueKey except if your add JRebirthWaves.REUSE_COMMAND WaveData)

as a reference check code of NotifierBase

final Command command = wave.contains(JRebirthWaves.REUSE_COMMAND) && wave.get(JRebirthWaves.REUSE_COMMAND)
                ? getGlobalFacade().getCommandFacade().retrieve((Class<Command>) wave.getRelatedClass())
                : getGlobalFacade().getCommandFacade().retrieve((Class<Command>) wave.getRelatedClass(), wave.getWUID());


Let me know if you have any remarks

[Sebastien Bordes]

I have done a worse affirmation:

The command will probably terminate in this order FUC-SUC-MUC

The JTP command terminates before the JAT one event it lasts more times because all commands triggered sequentially. (MultiCommand wait to receive a waveConsumed before launching the next command).

Have you solved your problem ?

Seb

[Vianney DEPAUW]

Sorry for the late answer I've been busy this week.

We understood what it was happening, and the solution you propose with WaveListener was exactly the one we used to fix this (except we didn't used a command for checking if the MMU is consumed).

The first post of this topic was more for indicate a situation which can happen in some cases, and can be a source of incomprehensible bugs.

But I think it's more a JRebirth concern, so a generic native solution could be integrated into the framework.

I didn't test your changements in 7.7.1-SNAPSHOT. We are still using JRebirth 0.7.6 in our projects, but will upgrade to 7.7.0 as soon as possible.

Thanks ;)

[Sebastien Bordes]

Yes, I think I could add a @SingleRun annotation that will check that only one Command is run at the same time but as it will have an high impact, I will probably perform it more globally with another thing I want to do (ScheduledCommand).

All these special commands will be managed by custom services, but currently it's just a conceptual vision....

Seb