synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject RE: startup order - correct place to start transport listeners
Date Sat, 04 Apr 2009 08:21:27 GMT
I put my comments inline as well.


	Please see my comments inline;

What I meant in my original proposal is exactly this, but without preStart I think preStart
is equivalent to the init, but we need postStart or some other meaning full method to do post
startup tasks. 

Yeah, at the moment I sent my mail out I also came across the same thought. Did you notice
my follow-up mail on this? I think we could put all calls in a start() method which delegates
to the specific sub routines in the appropriate order. Actually also the tasks are part of
the start process. It’s only the fact they are started after the listeners as they require
them to be started in advance.


This may not be just the tasks but also some mediators which requires to fetch some data from
outside going through the transport senders at the startup??

Can you give me an example here? It can’t be something which is done on mediate() as this
can only happen once a message arrives, and thus transports are started. So you are talking
about something which currently happens inside the init method, which requires the transports
to be available. Hmmm, interesting… I have no use case in mind. Maybe other can help on
this. Actually if this would be the case I would find it consistent to not only implement
ManagedLifecylce but rather Startup and split the implementation in a init-Phase were one
can only do initialisation stuff which does not require transports. And a start-Phase where
one can do any kind of one-time operation on startup also requiring the transports.

Of course this would break existing mediators currently doing such stuff. This is why I’m
asking about examples and use cases.

So if we add a new method to the ManagedLifecycle called start you could, support these post
startup work in a general manner rather than treating tasks starting as a special case.
True, implementation of mediators would need to be changed either the one or the other way.
I just don’t see so many use cases for the start()-method, but I may be wrong. Also any
mediator could decide to implement ManagedLifecycle or some more specific interface extended
by the startup behaviour. Otherwise you would often leave this method without implementation.

Ok, looking inside the Startup interface it only sounds to be generic but infact it seems
to be just a synonym for task, or?

So I could also life with a ManagedLifecycle interface extended by a new start() method keeping
this method always empty for my use cases. Of course this has also an advantage for the user.
Only one interface to care about.


What are other’s opinions? How shall we go on? Ruwan, would you do those changes on your
own. If you would need some support, I could do this today. Today I have some hours I could
spend. Tomorrow and next week doesn’t look too good on my side.

Otherwise I will proceed with my work on the JMX stuff to remove some open issues as of the
comments in the JIRA (the integration shouldn’t be done before the startup/shutdown has
been changed though, I will then sync and update my patch accordingly) and a small patch regarding
log output in the http transports. Looks like either way I will find enough useful stuff to
help with today.




View raw message