qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danushka.menikkumb...@gmail.com>
Subject Re: [jira] Updated: (QPID-2794) Broker shutdown logic needs changing to run inside another process
Date Fri, 13 Aug 2010 17:11:09 GMT
Hi Andrew,

Thanks a lot for your quick reply.

Why do you think what I have suggested is not the correct way to achieve
what I need?. I believe its the simplest approach to get it done.


On Fri, Aug 13, 2010 at 6:46 PM, Andrew Kennedy <
andrewinternational@gmail.com> wrote:

> > Broker shutdown logic needs changing to run inside another process
> > ------------------------------------------------------------------
> >
> >                 Key: QPID-2794
> >                 URL: https://issues.apache.org/jira/browse/QPID-2794
> >             Project: Qpid
> >          Issue Type: Bug
> >          Components: Java Broker
> >            Reporter: Danushka Menikkumbura
> >         Attachments: QPID-2794.patch
> >
> > At the moment the broker shutdown terminates the JVM which is a problem
> when the broker runs inside another process.
> Danushka, Hi.
> I understand what you are trying to do here, but I don't think this is
> the way to go about it. I assume you want to start the broker inside
> an OSGi container, and not kill the container when it stops, right?
> Can I suggest the following refactoring of our broker startup classes
> as the way forward, instead?
> Main
> - move startup and shutdown methods to the Broker class, and build a
> BrokerOptions configuration from the command-line options here. if
> this class has to shut down the broker it started, it can safely call
> System.exit as well, after telling the instance to shut down.
> Broker
> - represents a broker instance that can be started and shut down
> (methods from Main originally) where the startup method should take a
> BrokerOptions  configuration object. the instances would be created
> and methods called from Main, the BrokerActivator or possibly from a
> client wanting an in-vm broker. this class could also contain instance
> fields that represent ehther the broker is embedded and contain a copy
> of the OSGi context it is running
> BrokerOptions
> - the set of command-line options that are parsed out in the existing
> Main should be stored in a separate object, that can then be created
> independently for situations where broker startup does not happen on
> the command-line.
> BrokerActivator
> - OSGi activator that parses the configuration from a property file or
> similar to obtain a BrokerOptions and uses that to call startup on a
> Broker instance. similarly, when the Activator shuts down, it should
> shut the Broker instance down cleanly. this is distinct from the
> activator used by Felix when starting up our embedded container, and
> this is where you can set the flag that would indicate that the broker
> is embedded, so that the PluginManager knows not to start an OSGi
> container, but to use the existing OSGi context
> Hope this is useful, but it's just one way of doing things.
> Andrew.
> --
> -- andrew d kennedy ? edinburgh : +44 7941 197 134
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message