It's worth noting that if you happen to be using durable subscriptions (the
durable parameter is set to true in the JmsMessagingClient constructor) and
your client goes away, the broker will store messages until your client
re-establishes a connection. When your client reconnects, all of those
stored messages will be sent. If this is not what you want to happen, you
can either: 1. Not use a durable subscriber or 2. Make sure that you call
MessagingClient.stop(true) before your application terminates or 3.
Configure Fedora to use queues rather than topics. More info about durable
subscriptions can be found here:
http://activemq.apache.org/how-do-durable-queues-and-topics-work.html
As already mentioned, if you're not using a durable subscription, it's a
good idea to call stop() if that is possible, but it is not required.
Bill
On Mon, May 23, 2011 at 9:48 AM, <[email protected]> wrote:
> If your client is only receiving messages, then the Fedora JMS service will
> not be disturbed by it disappearing, although calling .stop may allow it to
> release some resources, depending on how you've configured your repository's
> Messaging module and ActiveMQ substrate.
>
> ---
> A. Soroka
> Online Library Environment
> the University of Virginia Library
>
>
>
>
> On May 23, 2011, at 3:21 AM, Conal Tuohy wrote:
>
> > I know very little about JMS but I have written a JMS Messaging client
> > to listen for changes to Fedora objects, using an instance of
> > org.fcrepo.client.messaging.MessagingClient.
> >
> > My application is a stand-alone application which does nothing but
> > listen for changes and propagate data elsewhere. If I terminate the
> > application, do I need to call MessagingClient.stop to stop listening
> > for notifications? Is the Fedora JMS service going to have a problem
> > otherwise?
> >
> > THanks!
> >
> > Conal
> >
> >
> > --
> >
> > Conal Tuohy
> > eResearch Business Analyst
> > Victorian eResearch Strategic Initiative
> > +61-466324297
> >
> >
> >
> ------------------------------------------------------------------------------
> > What Every C/C++ and Fortran developer Should Know!
> > Read this article and learn how Intel has extended the reach of its
> > next-generation tools to help Windows* and Linux* C/C++ and Fortran
> > developers boost performance applications - including clusters.
> > http://p.sf.net/sfu/intel-dev2devmay
> > _______________________________________________
> > Fedora-commons-developers mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Fedora-commons-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
