You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Danushka Menikkumbura (JIRA)" <qp...@incubator.apache.org> on 2010/08/13 08:36:15 UTC

[jira] Updated: (QPID-2794) Broker shutdown logic needs changing to run inside another process

     [ https://issues.apache.org/jira/browse/QPID-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Danushka Menikkumbura updated QPID-2794:
----------------------------------------

    Attachment: QPID-2794.patch

Please apply the attached patch to solve this issue.

Danushka

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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Re: [jira] Updated: (QPID-2794) Broker shutdown logic needs changing to run inside another process

Posted by "Sorin S." <ss...@gmail.com>.
Hi Danushka,
Is it possible to elaborate in more details what you are trying to achieve?

Thanks,

Sorin


On Fri, Aug 13, 2010 at 6:11 PM, Danushka Menikkumbura
<da...@gmail.com> wrote:
> 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.
>
> Thanks,
> Danushka
>
> 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
>>
>>
>



-- 
Sorin S

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Re: [jira] Updated: (QPID-2794) Broker shutdown logic needs changing to run inside another process

Posted by Andrew Kennedy <an...@gmail.com>.
On 13 August 2010 18:11, Danushka Menikkumbura
<da...@gmail.com> wrote:
> 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.

I just think it would be good to have a solution that everyone can
use. As far as I could tell, your patch adds a static method that
isn't called anywhere ekse, so I have to assume that you have an
activator or some other bit of code that sets the value to true? One
of the things that needs implemented in the broker is a way for it to
be embedded as an OSGi module in another application, and I think the
mechanism I outlined would accomplish this, i.e. by adding a
BrokerActivator and formalising the configuration that needs to be
passed into a broker on startup. Maybe you could add the activator
code to the patch as well?

Cheers,
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


Re: [jira] Updated: (QPID-2794) Broker shutdown logic needs changing to run inside another process

Posted by Danushka Menikkumbura <da...@gmail.com>.
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.

Thanks,
Danushka

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

Re: [jira] Updated: (QPID-2794) Broker shutdown logic needs changing to run inside another process

Posted by Andrew Kennedy <an...@gmail.com>.
> 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