Messaging resource issue

[senordhuff]

Hello,

We are using Smartclient messaging with JBOSS 5.0 JMS Topics. We are able to get this working but whenever a message is sent on the channel, a new subscription is added to the JMS Topic. So the number of subscriptions are increasing significantly and effecting the performance. We also see a new subscription whenever there is a connection timeout but the previous one is not getting closed.

I see a post regarding a similar problem, but seems there was no resolution: http://forums.smartclient.com/showthread.php?t=3130&highlight=messaging

The following are the messaging related entries in server.properties file:
messaging.keepaliveInterval: 30000
messaging.keepaliveReestablishDelay: 100000
messaging.connectTimeout: 4000
messaging.connectionTTL: 120000
messaging.dispatcherImplementer: com.chat.JMSMessageDispatcher

jndi.messaging.java.naming.factory.initial: org.jnp.interfaces.NamingContextFactory
jndi.messaging.java.naming.provider.url: jnp://localhost:1099
messaging.jms.context: messaging
messaging.jms.jndiPrefix:
messaging.jms.topicConnectionFactory: ConnectionFactory

Any ideas what could be going on?

[Isomorphic]

Hi senordhuff,

Is there any way you can package this up as a test case? We really need to see this happening and be able to inspect all the JBoss settings to figure this out.

[senordhuff]

Hi, I posted the files on your extranet support site for review. Let me know when you are able to take a look?

[Isomorphic]

Hi senordhuff,

Thanks for taking the time to put that together, we'll be looking at it in time to hopefully whack the bug, if there is one, for 7.0 final.

[senordhuff]

Hi, can you give me an update on whether you were able to correct any issues based on the test case provided for this awhile back?

[Isomorphic]

We have dug into this one deeply enough to disentangle whether there's a SmartClient problem here. However we are doing some related work in this area and it's likely to come up soon.

Are you considering migrating over to SmartClient messaging instead of your existing integration strategy? Do you have a timeframe in mind?

[SchlauKunde]

I am also very much interested to test-ride the SmartClient RTM Module with JMS Messaging Servers; for instance with JBoss Messaging or Apache ActiveMQ Messaging.

So first of all: Could You please explain more clearly the (forthcoming) state of the SmartClient RTM Module used in conjunction with JBoss and ActiveMQ ?

Secondly: Do SmartClient RTM 'channels' correspond to JMS 'topics' only ? Or to JMS 'topics' AND 'queues' ?

Thirdly: Great it would be if the SmartClient UI could react to (realtime) changes in the underlying data automatically and smoothly. Has SmartClient such convenient (realtime) UI reaction capabilities already built in ?

[lextra]

SGWT3.0 Pro
SmartClient Version: SC_SNAPSHOT-2012-02-23_v8.2p/PowerEdition Deployment (built 2012-02-23)
WebLogic 11G, 10.3.5

Has this issue been resolved in any way? We are seeing the same/similar behavior.

For each currently subscribed client:
At every reconnect (2 min), a new connection is created without closing the old connection.

Testing with just one client:
The creation of new connections stop when the client unsubscribes, but the current and old connections remain open.

As always, thanks for you assistance.

[Isomorphic]

lextra when you say a "connection" what do you mean (JMS registration, HTTP socket on server, HTTP socket on client) and what tool are you using to view "connections"?

[lextra]

JMS server connections (subscriptions) as seen through the WebLogic Admin console.
"A JMS connection represents an open communication channel between an application and the messaging system, and is used to create a session for producing and consuming messages." Image attached.

I am just at the beginning of investigating ... I simply wanted to know if anyone was still seeing this type of behavoir. I haven't launched enough clients yet to know the full impact. (need to inspect clients and server at the system level) Understand if you tell me you need more information.

[lextra]

We have decided to hold off on implementing the Realtime module for the time being.