So more on JMX & component life cycle.  Looked at example/basic and tried to stop/start timer.  QuartzComponent code will stop scheduler but it will never restart it as implemented,  it should look more like this:

    public void start() throws JBIException {
        try {
            scheduler.start();
            super.start();
        }
        catch (SchedulerException e) {
            throw new JBIException(e);
        }
    }

    public void stop() throws JBIException {
        try {
            scheduler.pause(); // causes triggers to stop firing
            super.stop();
        }
        catch (SchedulerException e) {
            throw new JBIException(e);
        }
    }
    public void shutDown() throws javax.jbi.JBIException {
        try {
            scheduler.shutdown(); // release scheduler resources
            scheduler = null;
            super.shutDown();
        } catch (SchedulerException e) {
                throw new JBIException(e);
        }
    }

Once the Quartz scheduler has been shutdown it can't be restarted as attempted in current code. You must instantiate a new scheduler as stated in Quartz doc.  While above code allows start/stop this still fails start after shutdown.

JBI spec says on pg 77 "For example, if the start() MBean control is invoked by a management tool on a component that is in the shutdown state, the implementation must, in sequence, invoke the ComponentLifeCycle’s init() and start() methods. "

After shutdown, invoking JBX start does not does not result in above behavior, QuartzComponent init method is never called.  In QuartzComponent init is where scheduler is instantiated, start depends on this.  I didn't find the MUST but it seems pretty clear that there are sequences and state transition that need to be managed by the JBI impl.



On Aug 30, 2005, at 4:22 PM, Lawrence Blanchette wrote:

I am poking at JMX component management with MC4J and see some odd behavior.  Using the file-binding example:

after startup and fileSender and filePoller currentState are queried they report "unknown" even though they are running.

once stopped/started currentState reports fine.

If I stop fileSender but leave filePoller running, fileSender still gets invoked when filePoller sends message.  I would expect once stopped messages would not not continue to be delivered.  Maybe 'cause they're POJOs or is it the routing style?

Other bean attributes like exchangeCount do not appear to be maintained.

Is this all just a todo/incomplete or am I misunderstanding?

Larry


Reply via email to