On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi, we are working with SCXML extensively for quite a while. Its a great tool, its saves a lot of development time and makes things easier. But there are some impacts we discovered: - After a period of time triggering a lof of events, that contain assignments, variable creations and notifications of the EventDispatcher, SCXML seems to loose memory.
<snip/> Requiring more memory when more variables and notifications are created is expected (and depending on what objects the variables are actually referencing this might be non-trivial), but a leak would actually constitute holding on to these references for too long (or eternity, even). Any particular bits where you think we should be letting go sooner?
- SCXML uses a lot of processor time, when large amounts of events with conditions are compared. A way to improve performance could be to compile JEXL expressions in TransitionTarget at load-time of the SCXML file.
<snap/> Fair enough, the real issue here is that while a particular expression language might afford us these conveniences, others may not and it does get slightly tricky when you abstract out to a EL-agnostic API (as Commons SCXML does) to do this at document load-time (where you don't care about the EL yet). However, there should probably be some caching strategy within the particular Evaluator implementation (in this case, JEXLEvaluator) where possible (so atleast when the same expression is evaluated repeatedly, it isn't reparsed). Another place where a performance penalty is incurred is to find the effective JEXL context since there are no "chained" contexts out of the box provided by JEXL. I keep meaning to add such an impl to JEXL, hopefully I'll get to it soon.
- For each TransitionTarget, a JexlContext is created. For us, it is very important to have one context with all variables that is valid for all TransitionTargets. Is there a simple way to achieve this?
<snip/> The SCXML Working Draft requires us to have separate contexts, so we can differentiate between the two "foo" variables here: <scxml ...> <state id="state1"> <onentry> <var name="foo" .../> </onentry> </state> <state id="state2"> <onentry> <var name="foo" .../> </onentry> </state> </scxml> I'm personally fine with providing a switch on the executor that allows turning this behavior off and creates a single / flat context for the entire document as long as that is conscious developer choice. If you want, you can open an enhancement request in JIRA [1] for this "non-standard" requirement. Finally, thanks for your feedback. Its critical to the component's continual improvement. -Rahul [1] http://issues.apache.org/jira/browse/SCXML
Regards, Heiko
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
