Eclipse Community Forums: Equinox » Timeout from ds.SCRManager

Home » Eclipse Projects » Equinox » Timeout from ds.SCRManager

Timeout from ds.SCRManager [message #115855]

Sun, 10 August 2008 05:32

Eclipse User

Originally posted by: ekkehard.gentz-software.de

sometimes I got a timeout - is this configurable ?

it happens while a long running process from Easybeans
(initializing PersistenceUnits, EJBs, Hibernate...)

thx

ekke

WARNING - 11:29:55 [B: org.eclipse.equinox.ds] - [SCR - WorkThread]
Timeout occurred! Thread was blocked on processing [QueuedJob]
WorkPerformer: org.eclipse.equinox.internal.ds.SCRManager@f669c0;
actionType 1.

Re: Timeout from ds.SCRManager [message #116323 is a reply to message #115855]

Wed, 20 August 2008 08:55

Eclipse User

> WARNING - 11:29:55 [B: org.eclipse.equinox.ds] - [SCR - WorkThread]
> Timeout occurred! Thread was blocked on processing [QueuedJob]
> WorkPerformer: org.eclipse.equinox.internal.ds.SCRManager@f669c0;
> actionType 1.

My understanding is that this is nothing to worry about. The warning is
really talking about an implementation detail since once the WorkThread
has timed out and terminated, another is started immediately.

I would guess that this might be a sign that a bundle is executing on a
callback and is taking too long, which is why you'll often see this
during debugging.

I would suggest opening a bug report for this, since the message should
probably not be shown, except during debugging/tracing.

Simon

Re: Timeout from ds.SCRManager [message #116332 is a reply to message #116323]

Wed, 20 August 2008 11:06

Eclipse User

Originally posted by: s.boshev.prosyst.bg

Simon Archer wrote:

> My understanding is that this is nothing to worry about. The warning is
> really talking about an implementation detail since once the WorkThread
> has timed out and terminated, another is started immediately.

> I would guess that this might be a sign that a bundle is executing on a
> callback and is taking too long, which is why you'll often see this
> during debugging.

> I would suggest opening a bug report for this, since the message should
> probably not be shown, except during debugging/tracing.

I think these warnings are important because when the SCR dispatcher
thread is replaced with another one it means the component being
initialized by the first thread is still not operating and it might have
been blocked forever. This warning indicates this might be a problem.
Generally if the problem is in the timeout (by default 30 seconds) and
there is a lot of initialization work which takes more than 30 seconds I
would recommend increasing the timeout to a suitable value (maybe 60 or
more seconds)to avoid the creation of new dispatcher thread.

Stoyan

Re: Timeout from ds.SCRManager [message #116335 is a reply to message #115855]

Wed, 20 August 2008 11:13

Eclipse User

Originally posted by: s.boshev.prosyst.bg

ekke wrote:

> sometimes I got a timeout - is this configurable ?

> it happens while a long running process from Easybeans
> (initializing PersistenceUnits, EJBs, Hibernate...)

You can use the system property "equinox.ds.block_timeout". By default its
value is 30000. You should try increasing it to a suitable value (maybe
60000 or more).

Stoyan

Re: Timeout from ds.SCRManager [message #116348 is a reply to message #116332]

Wed, 20 August 2008 13:15

Eclipse User

> I think these warnings are important because when the SCR dispatcher
> thread is replaced with another one it means the component being
> initialized by the first thread is still not operating and it might have
> been blocked forever. This warning indicates this might be a problem.
> Generally if the problem is in the timeout (by default 30 seconds) and
> there is a lot of initialization work which takes more than 30 seconds I
> would recommend increasing the timeout to a suitable value (maybe 60 or
> more seconds)to avoid the creation of new dispatcher thread.

Hi Stoyan

Yes, I agree with you. Maybe the warning could be enhanced to
communicate this to the developer. Today the warning is as follows:

> WARNING - 11:29:55 [B: org.eclipse.equinox.ds] - [SCR - WorkThread]
> Timeout occurred! Thread was blocked on processing [QueuedJob]
> WorkPerformer: org.eclipse.equinox.internal.ds.SCRManager@f669c0;
> actionType 1.

Maybe naming the component that is blocking would help point the finger
back at the developer. It might also be useful to say which method is
blocked.

Just a suggestion.

Thanks

Simon

Re: Timeout from ds.SCRManager [message #116362 is a reply to message #116348]

Thu, 21 August 2008 08:55

Eclipse User

Originally posted by: s.boshev.prosyst.bg

Simon Archer wrote:

> Maybe naming the component that is blocking would help point the finger
> back at the developer. It might also be useful to say which method is
> blocked.

I agree the current warning does not give enough information where the
problem is. I think I could print the component that stays in the root in
the component tree that is currently being built (note that activating a
component may lead to the synchronous activation/deactivation of
components that depend on that component). The problem is that the root
component might not be the problematic component, so I would print false
information. The best debug information that would help a developer to see
where exactly the problem is, would be to print the thread stack.
Unfortunately this is possible only on JDK1.6, because it has an API for
the retrieval of the stack trace of any thread.

Perhaps you should open a bug just to remind that we have something to
improve here. I think it would be possible to improve this warning at
least when running DS on JDK1.6.

Re: Timeout from ds.SCRManager [message #1761091 is a reply to message #116362]

Sat, 06 May 2017 09:43

Eclipse User

I have just run into this problem myself. Bundle A was timing out, but the problem was with Bundle B, that provided the service that bundle A needed. It appeard that the MANIFEST.MF of bundle B was giving a warning that its Bundle-Activation Policy was not set to 'lazy'. When I changed this everything worked fine. I thought I'd share this finding, as it may be one of the most frequent causes of problems

Previous Topic:	OSGI Whiteboard registered Resource not working
Next Topic:	Optional dependencies not resolved for some plugins

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Mar 16 15:42:46 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter