[sfcoy]

Actually , I retract that. Something made me think that @Remove should be applied to the interface. It must be on the implementation class, where it works as advertised.

[sfcoy]

Working example attached...

[mick_mcgovern1]

thanks for this, We have the remove method on the interface (but we also have it annotated on the interface - removing the annotation from there didn't seem to make a difference).  I still can make it run out of memory and never see PreDestroy called or any of the SFSB not show up in the dump.!  But I'll keep looking.

[mick_mcgovern1]

the difference is that we have an abstract superclass, the remove method on the superclass is called but doesn't have the effect. Only when the method is in the instantiated sub-class does it work. Is there not a way of avoiding putting this code into each of our 1000 SFSB?

[jaikiran]

You'll have to show us the exact code along with the annotations used.

[mick_mcgovern1]

Here is the code

@Local

public interface TranProcessorLocal extends

Serializable {

public void

remove();

public void process(TranRequest request, TranResponse response);

Abstract  super class - remove method has no affect:

public abstract class BaseTranProcessorBean implements TranProcessorLocal {

....

@Remove

public void remove() {

}

And then the sub-class (originally didn't have remove method - adding one fixes the issue - I just dont want to have to add it to all the subclasses)

@Stateful(name = "ApplyStandingInstructions")

public class ApplyStandingInstructionsBean extends

BaseTranProcessorBean {

Our system has about 1000 different transaction processing classes - all SFSBs and mostly subclasses on the above mentioned class BaseTranProcessorBean.

Perhaps we need a @Stateful on the abstract super class? I'll try that. [update]Didn't help - looks like I need the "remove" code in each subclass!

[jaikiran]

It should work if the base class contains the @Remove on the method. If it isn't then it's a bug. Here's what the spec says:

EJB 3.1 spec, section 4.9.2:

The session bean class may have superclasses and/or superinterfaces. If the session bean has superclasses, the business methods, lifecycle callback interceptor methods, the timeout callback methods, the methods implementing the optional session synchronization notifications,,the Init or ejbCreate<METHOD> methods, the Remove methods, and the methods of the SessionBean interface, may be defined in the session bean class, or in any of its superclasses.

Please file a JIRA if that isn't working.

[mick_mcgovern1]

oh good, I'm pretty sure this worked in 4.2.3

I'll file the Jira.....

[javacoryd]

Was this issue ever resolved or was a JIRA filed for this?  We are seeing the same thing on our app that we ported from JBoss 4.2 to JBoss 7.1.1 Final.

Thanks,

Cory.

[sfcoy]

If you're not in a position to use EAP 6.x in production then you should consider checking out and building 7.1.3 or 7.2.0 from https://github.com/wildfly/wildfly.

[javacoryd]

Thanks Stephen.

Yea, I patched our server with the fix and the memory leak is gone.

Cory.

[zurchman]

Just want to say thanks for the sfsb test.

We ran into a huge SFSB memory leak while porting an EJB 2 project to 7.1.1.Final.  There was some question about 7.1.1 working correctly, but we encountered the same leak with both EAP 6.1 and Wildfly 9.0.2.Final.

Your test ran fine on 7.1.1 which sent us back to the application and allowed us to identify the incorrect behavior, plug the leak and preserve our sanity.

Thanks again!