memory problem

[Former Member]

Hello,

I've written a java-servlet that opens a lot of JMS EventListeners. The problem is, that when more then 92 EventListeners should run together, I get a not-enough-memory-error. Is their a limit for applications running in the web container or are there some settings to increase the memory that can be used? I tried to increase the memory for the complete VM with the config tool. but this didn't changed everything.

best regards,

Remo

[Former Member · Accepted solution]

Hi Remo,

That's a feature to prevent application opening too many resources and crashing the server with OOM. If you want to increase that number you need to increase the setting - clientMemorySize of the JmsProvider service. You can check :

<a href="http://help.sap.com/saphelp_nw04/helpdata/en/a9/ad3d9ef22e4b2ea9752de8d98db5a4/frameset.htm">JMS provider properties</a>

Btw, as per the Java EE spec, MessageListeners should not be used out of the web container. The recommended way is to use MDBs. The server is allowed to throw an exception in case MessageListeners (i.e. listeners with onMessage method are being used.) Please be advised that since that is not according to the spec, usage of MessageListeners can be not supported in future server versions.

HTH

Peter

[Former Member · Accepted solution]

Thx Peter. That was the problem.

Stoyan Vellev send me this also:

"JMS Consumers (message listeners) are heavyweight objects, due to the client-side message cache they are associated with.

To protect the server from an OutOfMemory, the number of consumers you can run in parallel is limited by two memory management properties of the JMS Provider:

clientMemorySize

Scope= JMSProvider->Global->Client-side

Default value= 10MB

Explanation= This is the total amount of memory a JMS client can occupy.

Recommended value= At least clientConsumerBuffer * maximum number of parallel message consumers registered

Significance= The implication of increasing this is that the JMS client will occupy more memory, and thus might affect the performance of other components and applications. Also note that the value of clientMemorySize / clientConsumerBuffer = Maximum Number of parallel consumers supported, if this is exceeded, registering new consumers will start failing with memory-management exceptions.

clientConsumerBuffer

Scope= JMSProvider->Global->Client-side

Default value= 100 KB

Explanation= This is the amount of memory a JMS consumer can use for its message buffer (to pre-fetch messages from the server), i.e. this is the size of the client-side in-memory message cache per consumer.

Recommended value= At least the size of the largest expected message.

Significance= Lower values will deteriorate performance due to system packets exchange between the client and server for frequent expanding and shrinking of the buffer. The value must be coordinated with the value of clientMemorySize and the maximum number of parallel message consumers.

In a nutshell, if you want to support larger number of parallel consumers, you should increase clientMemorySize and/or decrease clientConsumerBuffer.

You can change these properties from the offline configuration editor (the properties are under “jms_provider/DEFAULT/default” for NW04/NW04s and under “jms_provider/default/Propertysheet data” for 7.10) and they will become effective after a server restart."

@Peter again: To you btw.: Yes, I know that. But the problem is, that it is very difficult to start a new dynamically MDB at runtime. Because in the tutorials I read, I have to setup xml-configuration files. If you have code/tutorials that shows how that can be done dynamically, let me know .... that would very helpfully.

[Former Member · Accepted solution]

Hi Remo,

I am not sure why you want to start dynamically MDB-s, typical web container activity is assoicated with user interraction (user requesting some page) and there the synchronous API-s (receive(), receiveNoWait(), etc. for checking for messages is more appropriate...

Btw, since that question is probably not that interestng for the whole community we could continue by email discussing the use case. After all we both have sap email addresses

Best Regards

Peter