synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Linton <ruwan.lin...@gmail.com>
Subject Re: startup order - correct place to start transport listeners
Date Sat, 04 Apr 2009 11:41:02 GMT
Hi Eric,

On Sat, Apr 4, 2009 at 1:51 PM, Hubert, Eric <Eric.Hubert@foxmobile.com>wrote:

>  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.
>
How can we manage the case where the task sends a request out just after its
initialization and before starting the listeners without having a post
listener start phase to start the tasks, for example MessageInjector
actually does this.

>
>
> 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.
>
True, I agree with all your concerns, but my point is that if we take just
the tasks out of the normal ManagedLifecycles and call them after starting
listeners, we are going with an assumption that task initialization is the
one only requires transport listeners.... This is a bit confusing because we
are using the same interface to mean two types of implementations and we
manage them depending on our hard coded assumptions.

I don't have a concrete example of such a case, but I think a start method
apart from the init method is required. I am not in favor of adding this to
the startup interface, because it is not intended to mark a life cycle
rather it is a concrete component of the synapse.... Startup interface can
be treated as same as the Mediator interface and the Task is the interface
that we provide for the external users to write one type of startups, which
is a quartz scheduled piece of work executed as Tasks. This is analogous to
the Command mediator, Command Mediator is an implementation of the Mediator
interface, where it provides the Command interface for the external users to
write there own commands.

One option would be to come up with a new interface to cope this new start
method requirement which is extended from the ManagedLifecycle interface,
but it introduces a new interface yet again keeps the back words
compatibility for the already existing mediators. We should properly
document this so that if a particular mediator wants to get this starting
behavior it can also use the new derived interface over the
ManagedLifecycle.

>
>
> 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.
>

+1, it is not going to be a Startup derived interface rather a new interface
derived from the ManagedLifecycle, because Startups are more specific to
task like components, with some more methods in it.

>  Ok, looking inside the Startup interface it only sounds to be generic but
> infact it seems to be just a synonym for task, or?
>
Not really a synonym, I think I explained the relation between Startup and
Task in the above section.

> 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.
>
Agree, we could provide a abstract class with the startup method implemented
to get rid of the blank implementation in each and every mediator. I prefer
to change the ManagedLifecycle interface itself, but OK with going for a new
interface as well.

>
>
> What are other’s opinions? How shall we go on? Ruwan, would you do those
> changes on your own.
>
I would like to do this on my own, after gathering the feedback and I think
even now we are clear about certain things... so I will get started.

> 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.
>
Eric, I think it is better to do this by one person, after the
implementation is completed I will let you all know for a review and for any
changes/improvements. I think that is the practical model for this sort of a
change. :-)

> 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.
>
+1

Thanks,
Ruwan

>
>
> Regards,
>
>    Eric
>



-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Mime
View raw message