Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313499

Summary:	Counter values remain in memory even after workflow is completed and cannot be reset
Product:	[Modeling] M2T	Reporter:	Daniel Luebke <eclipse>
Component:	Xpand	Assignee:	Project Inbox <m2t.xpand-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	sven.efftinge
Version:	unspecified	Flags:	sven.efftinge: helios+
Target Milestone:	RC
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Daniel Luebke

2010-05-19 06:04:18 EDT

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

Comment 1 Sven Efftinge

2010-05-19 08:06:13 EDT

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).

Comment 2 Daniel Luebke

2010-05-19 08:15:21 EDT

(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.

Comment 3 Sven Efftinge

2010-05-19 17:49:43 EDT

(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.

Comment 4 Jochen Schmich

2010-05-20 03:20:53 EDT

Please see Bug 310361 - Same issue and more

Comment 5 Karsten Thoms

2013-02-21 08:11:00 EST

Bug resolved before Xpand 1.2 release date => Closing