Community
Participate
Working Groups
Build Identifier: M20090917-0800 When using the counter extension, the counter values remain in memory even after the workflow is completed. In server-side deployments this poses some problems: - when the workflow is executed multiple times, problems can arise because the counters are not cleanly initialized - when the workflow is started from a Java application, the counters remain in memory and add to the memory footprint. Even memory leaks can arise. IMO following additions should be made: 1. add a reset() method to the counter class and make it available by the Xtend facade 2. add a new CounterResetComponent that can be used inside a workflow for resetting the counter system 3. possibly add an option that counters are automatically destroyed after a workflow is completed (successfully or unsuccessfully). As a result in our project we wrote our own counters which can do 1 + 2. Reproducible: Always Steps to Reproduce: 1. create Xtend or Xpand using counters and a workflow using it 2. run the workflow 3. re-run the workflow 4. see side-effects and additional memory use
Haven't looked into or used the stdlib stuff. The design seems to be questionable at least. But it seams that there is a 'counterReset(Object o)' extension in the current HEAD (i.e. 1.0.0 RC1).
(In reply to comment #1) > Haven't looked into or used the stdlib stuff. The design seems to be > questionable at least. Yes, that's always the thing, if there are too many statics... Unfortunately, I don't see any alternative except passing counter objects around which would polute the parameter list quite a lot. > But it seams that there is a 'counterReset(Object o)' extension in the current > HEAD (i.e. 1.0.0 RC1). Yes, but this clears one counter only. Therefore, you have to identify if the counter is used the last time or which counters have been used before. Both of them are very hard to do if the transformation reaches a certain complexity.
(In reply to comment #2) > (In reply to comment #1) > > Haven't looked into or used the stdlib stuff. The design seems to be > > questionable at least. > > Yes, that's always the thing, if there are too many statics... Unfortunately, I > don't see any alternative except passing counter objects around which would > polute the parameter list quite a lot. > I would prefer passing that information explicitly before having global counter vars. Anyway, we should use Xpand's concept of global vars instead of Java statics, because their lifecycle is only bound to the execution context. I have fixed this in HEAD accordingly.
Please see Bug 310361 - Same issue and more
Bug resolved before Xpand 1.2 release date => Closing
