On 10/08/2010 19:53, David Conde wrote:
Just to let people know, I've worked around this by only creating one
SessionConfig object and caching it i.e "StatelessKnowledgeSession
ksession =
kbase.newStatelessKnowledgeSession((KnowledgeSessionConfiguration)getSessionConfig());".
What seemed to be happening was ChainedProperties was trying
Classloader lookups that were very slow when running in an OSGi
environment.
Also with how the OSGi bundles are built the org.drools package is
split and it makes it difficult to load up certain classes. I ended up
having to use reflection to load up the SessionConfiguration class
from a specific bundle. Maybe it's to do with how I'm importing the
drools bundles into my project but it's one to watch out for if your
using drools with OSGi.
in general you shouldn't be looking up concrete implementations, just
using what the factory services provide in drools-api; so the split
packages shouldn't impact. I made a few of the services avaiable as osgi
factory services, see docs for more details.
Mark
Thanks,
Dave
On 10 August 2010 17:46, David Conde <[email protected]
<mailto:[email protected]>> wrote:
ChainedProperties lives in org.drools.util.ChainedProperties and
is created in SessionConfiguration(). The call is called
during StatelessKnowledgeSession ksession =
kbase.newStatelessKnowledgeSession();.
On 10 August 2010 17:36, Pavel Tavoda <[email protected]
<mailto:[email protected]>> wrote:
Can't you avoid using ChainedProperties, what is it? Can you send
piece of code where you create session?
Pavel
2010/8/10 David Conde <[email protected]
<mailto:[email protected]>>:
> Hi Pavel,
> I've changed it over to use a stateless session and I'm
seeing the
> same behavior. I've done some debugging and it seems to be
very slow loading
> up the SessionConfiguration due to all of the loading that
happens in
> ChainedProperties.
> Thanks,
> Dave
>
> On 10 August 2010 13:53, Pavel Tavoda
<[email protected] <mailto:[email protected]>> wrote:
>>
>> Interesting. Normally it should be fast. Try to change your
patter and
>> load binary compiled serialized package from disk. You can
find it in
>> documentation.
>> Also consider using stateless session. Do you really need
stateful
>> session?
>>
>> Pavel
>>
>> 2010/8/9 David Conde <[email protected]
<mailto:[email protected]>>:
>> > Is it possible that this might be invoking the compiler
when a session
>> > is
>> > created? I have all of the init code in the service start
call and
>> > stored as
>> > members of the service for reuse but I must create a new
knowledge
>> > session
>> > for each run.
>> > Any ideas?
>> > Thanks,
>> > Dave
>> >
>> > ---------- Forwarded message ----------
>> > From: David Conde <[email protected]
<mailto:[email protected]>>
>> > Date: 9 August 2010 11:17
>> > Subject: Re: [rules-users] CPU Spike creating a
StatefulKnowledgeSession
>> > using OSGi
>> > To: Rules Users List <[email protected]
<mailto:[email protected]>>
>> >
>> >
>> > The line that it spikes on is StatefulKnowledgeSession
ksession =
>> > kbase.newStatefulKnowledgeSession();.
>> > Cheers,
>> > Dave
>> >
>> > On 9 August 2010 11:09, Pavel Tavoda
<[email protected] <mailto:[email protected]>> wrote:
>> >>
>> >> Is it session creation or rule compilation?
>> >>
>> >> Pavel
>> >>
>> >> 2010/8/9 David Conde <[email protected]
<mailto:[email protected]>>:
>> >> > Good Morning,
>> >> > I now have drools running on the Spring DM-Server but
I am seeing a
>> >> > CPU
>> >> > spike when creating a StatefulKnowledgeSession. I've
tested this
>> >> > outside
>> >> > of
>> >> > an OSGi environment and I don't see the spike. Does
anyone know any
>> >> > settings
>> >> > that I can change that might make this go away?
>> >> > Thanks,
>> >> > Dave
>> >> >
>> >> > --
>> >> > David Conde
>> >> > CTO Calom Technologies
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > rules-users mailing list
>> >> > [email protected]
<mailto:[email protected]>
>> >> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> rules-users mailing list
>> >> [email protected]
<mailto:[email protected]>
>> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > [email protected]
<mailto:[email protected]>
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>> >
>>
>> _______________________________________________
>> rules-users mailing list
>> [email protected]
<mailto:[email protected]>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> [email protected] <mailto:[email protected]>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-users
--
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
