Hi Ruwan,
thanks for taking the time to review the startup/shutdown logic implemented. In terms of structure and readability I also widely liked the changes. I have only those real world usage’s concerns. So if you are already at it could you please also look at the shutdown process! In most situations the correct shutdown order is exactly the opposite of the startup order. And honestly, this is what I also would expect here. Specifically please have a look at ServerManager.doStart() versus ServerManager.doStop()! Start: Create Synapse Configuration Create Synapse Environment Stop: Destroy Synapse Configuration Destroy Synapse Environment Destroy <-- only here listeners will be stopped (in the mean time the instance keeps accepting requests which can’t be processed as everything else has already been stopped/deactivated) To me this looks wrong. Regards, Eric ________________________________ From: Ruwan Linton [mailto:[email protected]] Sent: Thursday, April 02, 2009 3:59 AM To: [email protected] Subject: Re: startup order - correct place to start transport listeners I went through the new synapse startup logic and it seems OK but this makes the following concrete changes to the synapse architecture * Synapse can no longer be deployed just as a pure module in axis2, it requires much more work. * The message mediation is restricted to HTTP and HTTPS, which I am not sure whether we want to keep it as it is. But still this new logic even doesn't address the original problem in the discussion. In the new logic transport listeners starts even before the mediators getting loaded into synapse. I think we need to improve this, and to me Eric's point is completely a valid point. I will further look into resolving this and will keep the list posted.
