Recommanded J2EE design pattern
I have a program with the following design:
one WebService
which calls one EJB (Session bean).
The EJB is calling one of 9 STATIC(!) methods (depends on parameter that webservice accept) which can call another static methods etc...
I know this design is bad, and I want your recommended design for this application.
I am getting an outOfMemory exception when i run a loop that calls this webservice for many time.
Is there any design which may help me avoid this outOfMemory exception ?
Again , please refer this:
** one webservice
** one ejb who calls to static methods - depends on parameter that webservice accept.
Thanks
> I have a program with the following design:
> one WebService
> which calls one EJB (Session bean).
Stateless session bean? Or stateful?
> The EJB is calling one of 9 STATIC(!) methods
why is that so shocking?
> (depends on parameter that webservice accept) which
> can call another static methods etc...
which means all static variables. how deep does this stack go? none of these objects can be GC'd. how many are there?
> I know this design is bad, and I want your
> recommended design for this application.
Can't recommend much based on this information.
> I am getting an outOfMemory exception when i run a
> loop that calls this webservice for many time.
What else does the stack trace tell you?
How much memory do you have allocated for the JVM? Have you run JVMStat to see what's happening? Do you have a profiler to tell you where all these objects are coming from? The static objects all go to perm space and stay there. Do you see the perm space growing until it hits the max and then you get the OOM error?
> s there any design which may help me avoid this
> outOfMemory exception ?
Why must all those methods be static?
Why can't the SLSB have several methods that the webservice can call, based on that parameter? Let the web service figure out what to call.The EJB shouldn't have that logic inside it.
> Again , please refer this:
> ** one webservice
> ** one ejb who calls to static methods - depends on
> parameter that webservice accept.
The statics and the parameters are the likely causes. The SLSB is badly designed. Give it several methods and get rid of the statics.
Need more info, but that's my best guess.
%
Are you sure you know where the OOM error is coming from?
Do you have a profiler handy where you can see where all the objects are coming from? Could be a foolish thing with Strings or another bad practice that's hosing you.
It's not a pattern problem, it's just bad coding practices.
%
Hi duffymo, Thanks for attention
answers :
1) its a stateless session bean
2) The out of memory error happens when i am running the application from 150 clients repeatly as a load test
3) you say : "none of these objects can be GC'd" , why is that ?
4) The stack trace shows an outOfMemory exception and can happen in any phase, after ~X times.(depends on free JVM memory).
5) I can't run a profiler on this machine because of a technical reasons.
6) I indeed saw the perm space growing with systemout methods
The big question is about the coding,
1) is there anyway to improve this kind of code writing ?
2) Will the GC run better if these methods would be running from a nonstatic source ? should i write classes for these methods and invoke an object for each call ?
3) Should i write 9 SLSB and let the webservice decide which one to call ? or should i write one SLSB with 9 methods and let the webservice
decide which method to call ?
are the 3 questions above have anything with memory/GC performance ?
Thanks
> Hi duffymo, Thanks for attention
Hi George, it's my pleasure. Maybe we'll both learn something here.
> answers :
> 1) its a stateless session bean
Very good. Any private data members in that SLSB?
> 2) The out of memory error happens when i am running
> the application from 150 clients repeatly as a load
> test
Are you monitoring memory using a tool like JVMStat from Sun, OptimizeIt, or JProbe? I'd recommend it.
How much memory have you allocated to the JVM? What are the -Xms and -Xmx settings? Have you tuned any other JVM settings for memory and GC?
> 3) you say : "none of these objects can be GC'd" ,
> why is that ?
A static object is associated with a class. Once a class is loaded by the JVM it's never unloaded. The static objects will remain in memory for as long as the class does.
> 4) The stack trace shows an outOfMemory exception and
> can happen in any phase, after ~X times.(depends on
> free JVM memory).
Objects aren't being cleaned up. You're hanging onto references, so the GC can do its job.
> 5) I can't run a profiler on this machine because of
> a technical reasons.
You can certainly run JVMStats. It's non-invasive.
> 6) I indeed saw the perm space growing with systemout
> methods
>
> The big question is about the coding,
> 1) is there anyway to improve this kind of code
> writing ?
Undoubtedly yes.
> 2) Will the GC run better if these methods would be
> running from a nonstatic source ? should i write
> classes for these methods and invoke an object for
> each call ?
If the methods are all related, differentiated only by a parameter, why have nine objects? Why not one SLSB with nine methods?
> 3) Should i write 9 SLSB and let the webservice
> decide which one to call ? or should i write one SLSB
> with 9 methods and let the webservice
> decide which method to call ?
I'd try the latter.
> are the 3 questions above have anything with
> memory/GC performance ?
I don't know without more info.
%
