Could this be related to the issue at
https://issues.jboss.org/browse/JBRULES-3721? It started with performance
issues but eventually led to this case where a NPE is thrown by the
expire/retract action. They seem quite similar and perhaps the issue
attached project could help solve this issue as well.
laune wrote
The original post mentioned "performance tests with Drools
Fusion" in
combination with using the feature of automatic event retraction. I
don't think that OutOfMemory problems in this kind of scenario are due
to some bug in Drools (Fusion) - at least not until I see a complete
test app that reproduces the claimed problem.
It's important to note that automatic event retraction incurs a
considerable overhead in addition to the work required for getting the
event fact off the Rete
network. Essentially, a "Job" (i.e., the retraction) is scheduled for
punctual execution using a TimerService. One must therefore take care
that the system can cope with the additional work of disbanding all of
this contraband - otherwise it'll just clog, and croak.
Running fireUntilHalt() in one thread while inserting events from
another one and expecting automatic event retraction to happen after
10s (due to a window:time(10s)) is one way of risking that the system
runs into overload. With time slices being allotted equably to
threads, a backlog will accumulate if the expire/retract takes longer
than the insert/start-timer.
I've run the aforementioned scenario with System.sleep(nms) after
every so many insertions, and this keeps the system in balance.
Reducing nms gradually will - eventually - stress the system beyond
its breaking point, and OutOfMemory occurs. (To fill up memory more
quickly, the Event class was stuffed with some "dead data" -
char[2000].)
-W
_______________________________________________
rules-users mailing list
rules-users@.jboss
--
View this message in context:
http://drools.46999.n3.nabble.com/Garbage-collection-and-sliding-windows-...
Sent from the Drools: User forum mailing list archive at
Nabble.com.