[DROOLS-483] fix the repeated look-up of absent services #335

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@fpavageau

Some services accessed through the ServiceRegistry are not provided by
Drools modules but by jBPM, and have a higher probability of not
actually being in the classpath. ProcessBuilderFactory and
ProcessRuntimeFactory (try to) load such services when respectively
called during the construction of KnowledgeBuilderImpl and
StatefulKnowledgeSessionImpl. Trying to load a class is an expensive
operation, especially in the context of a web application where the
classloader will scan all the jars. With Tomcat for example, this
operation is moreover synchronized and can lead to lock contention.

There's also the issue of using exceptions for the regular control flow,
because filling an exception's stacktrace is also quite expensive.

ProcessBuilderFactory is modified to only try to load the service once,
and then either stores the service or the exception. The exception can
then be rethrown on subsequent accesses, to keep reporting on the failure
to load the service in KnowledgeBuilderImpl.

ProcessRuntimeFactory is simply modified to try to load the service once
and return null is the service cannot be loaded, simplifying the control
flow in StatefulKnowledgeSessionImpl.

@fpavageau fpavageau [DROOLS-483] fix the repeated look-up of absent services
Some services accessed through the ServiceRegistry are not provided by
Drools modules but by jBPM, and have a higher probability of not
actually being in the classpath. ProcessBuilderFactory and
ProcessRuntimeFactory (try to) load such services when respectively
called during the construction of KnowledgeBuilderImpl and
StatefulKnowledgeSessionImpl. Trying to load a class is an expensive
operation, especially in the context of a web application where the
classloader will scan all the jars. With Tomcat for example, this
operation is moreover synchronized and can lead to lock contention.

There's also the issue of using exceptions for the regular control flow,
because filling an exception's stacktrace is also quite expensive.

ProcessBuilderFactory is modified to only try to load the service once,
and then either stores the service or the exception. The exception can
then be rethrown on subsequent accesses, to keep reporting on the failure
to load the service in KnowledgeBuilderImpl.

ProcessRuntimeFactory is simply modified to try to load the service once
and return null is the service cannot be loaded, simplifying the control
flow in StatefulKnowledgeSessionImpl.
e461102
@mariofusco
Member

I merged what you did and fixed it when running in OSGi. Thanks a lot.

@mariofusco mariofusco closed this Sep 23, 2014
@fpavageau

Great, thanks a lot to you. 👍

I have a related question though, if I may: where are the resetInitialization() methods called from? Is it configured somewhere in the OSGi manifest (or an OSGi convention so it happens automagically)?

I couldn't find it in drools or droolsjbpm-knowledge.

@fpavageau fpavageau deleted the fpavageau:DROOLS-483 branch Sep 23, 2014
@mariofusco
Member

The resetInitialization() methods are called in the jbpm osgi activators for those services: droolsjbpm/jbpm@dc8e836

Sorry again for the huge delay in merging this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment