Hi Carsten, I still haven't found a way to know, programmatically, that a service has been blacklisted so that I can re-register (the code suggests that it unregisters the handler for you upon blacklisting).
That's the solution we're pursuing; adjusting the timeout for the service in question. Thanks! Adam From: Carsten Ziegeler <[email protected]> To: [email protected], Date: 10/20/2013 08:58 AM Subject: Re: EventAdmin Blacklist Hi, the event admin spec states that an event handler should consume the event as fast as possible. So in most cases you should process the event asynchronously. Once a handler is blacklisted, the only way to get it enabled again is right now to unregister and register the handler again. If you're using the Apache Felix implementation and know what you're doing :) you can configure it to never blacklist specific handlers (see http://felix.apache.org/site/apache-felix-event-admin.html for the ignore timeouts configuration). We usually set this for known handlers which we trust and leave it on for everyone else. Carsten 2013/10/18 Adam Wilson <[email protected]> > Hi Benjamin, > > The Thread.sleep() was an attempt to create a blacklisted service to see > what else happens in the container when blacklisting occurs. > > The service that was blacklisted is the head of a chain of events and is > fired on a timer. It's unlikely but possible that the chain of events took > longer than 5 seconds, in which case, we do want to fail fast---but we > would also like to recover. It seems like the only option is prevention > (wrap it in a thread or disable/increase the timeout). > > Thanks, > Adam > > [image: Inactive hide details for Benjamin Debeerst ---10/18/2013 12:46:31 > PM---Hi Adam, I'm not exactly sure which circumstances lead]Benjamin > Debeerst ---10/18/2013 12:46:31 PM---Hi Adam, I'm not exactly sure which > circumstances lead to a blacklisting, but we have also experienc > > From: Benjamin Debeerst <[email protected]> > To: "[email protected]" <[email protected]>, > Date: 10/18/2013 12:46 PM > Subject: RE: EventAdmin Blacklist > ------------------------------ > > > > Hi Adam, > > I'm not exactly sure which circumstances lead to a blacklisting, but we > have also experienced blacklisting in case of Exceptions and long-running > event processing. You should keep in mind that the EventAdmin may process > the event delivery for each event synchronously to the different listeners, > so when doing stuff like Thread.sleep(...) you might actually prevent other > listeners to be notified in time. > > We solved the problem by unpacking the relevant information from the > delivered Event object and putting that into a Queue, which in turn is > processed asynchronously. This allows to minimize the processing time and > the number of exceptions that can rise. > > (Also see OSGi r4 enterprise specification, chapter 113.8.2: Dealing with > Stalled Handlers. "Event handlers should not spend too long in the > handleEventmethod.") > > Regards, > Benjamin > > -----Original Message----- > From: Adam Wilson [mailto:[email protected] <[email protected]>] > > Sent: Freitag, 18. Oktober 2013 18:30 > To: [email protected] > Subject: EventAdmin Blacklist > > > > Hi all, > > We're experiencing a blacklist of a crucial service on a remote system and > have not been able to replicate it locally. > > Once a service has been blacklisted, what can we do about it? From the > EventAdmin code, it emits a log message and releases the service. There > doesn't appear to be any way to detect the blacklisting and mitigate it. > Ideally, it seems like a BLACKLIST event should be emitted so that you can > set up handlers to manage these situations---but, obviously, that could get > mess.. > > We're also having a hard time creating a circumstance that creates a > blacklisted service to inspect what happens. Is there an easier way to > simulate blacklisting? > > Below is the code that I tried to get something blacklisted, but it did > not work. > > Thanks! > Adam > > package osgi.event; > > import aQute.bnd.annotation.component.Activate; > import aQute.bnd.annotation.component.Component; > import aQute.bnd.annotation.component.Deactivate; > import aQute.bnd.annotation.component.Reference; > > import org.osgi.framework.BundleContext; import > org.osgi.service.event.Event; import org.osgi.service.event.EventAdmin; > import org.osgi.service.event.EventConstants; > import org.osgi.service.event.EventHandler; > > import java.util.HashMap; > > > @Component(immediate=true, name="tester", > properties=EventConstants.EVENT_TOPIC+"=testingevent") > public class Tester implements EventHandler { > public static EventAdmin event; > @Reference > public void setEvent(EventAdmin e) { event = e; } > > @Activate > public void start(BundleContext ctx) throws Exception { > event.postEvent(new Event("testingevent",new HashMap<Object,Object> > ())); > } > > @Override > public void handleEvent(final Event event) { > System.out.println("Event received, sleeping."); > Thread.sleep(10*1000); > System.out.println("Awake."); > > } > } > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- Carsten Ziegeler [email protected]
