we have an external system(JMS Provider) which accepts JMS messages as input.
for the connection to be established we have created a JMS connection(for conencting to JMS provider) in IS → Settings–>Messaging–> createJMSconnection Alias.
here we are creating connection using Native webMethods API(not using JNDI).
we are running JMS scripts for client creation in mywebmethods.
when we run the scripts for the 1st time we can see the clients in MWS as connected to the JMS provider.
last week we had a problme that JMS clients are getting dissabled(no connection is establised with JMS provider,which we can see in MWS), and when ever there is a problem JMS provider which is external system here is restarting there JMS related services and the connection is Up,and again after some its getting dissabled we analysed that and found problem as to keep a keep alive time internal.
we have kept a keepalive time interval and restarted the JMS related services from JMS provider side which has enabled the JMS queue clients.
this was working fine…

but now problem is today our broker server went down and started again due to which again the JMS clients got dissabled(connection was lost),now what should we do for enabling the JMS clients from IS or broker point of view coz each time when our broker is down we cant ask the external system to restart there JMS services(even for WM broker mistake)
i think u r getting what i mean exactly.
as JMS provider is external system we are loosing connection with taht frequently how we can establish the connection??
Could any one help me? what needs to be done?

Thx in Advance

Hi sujith, we are having the same issue. Can you tell me how you have resolved it ?

Thanks a lot…

Hi,

we have set some optmise rules which will alert us when ever those queues are down.
as we are not JMS providers here we cant do any thing(as far as i know)
So external systems(JMS Provider) are restarting ther JMS related services when ever the connection is lost.

Thanks for the reply… Right now we are restarting the IS and Q’s are showing connected since its webMethods issue but we may have to consider all the options in the hand.

Hi,

We are facing similar kind of issue. We are using webMethods broker as JMS provider and MDBs on WebSphere application server are consuming the messages from WM Broker’s queues. All the setup works and JMS communications works as expected. The issue we are seeing is, whenever WM Broker is down(these are scheduled outages for maintenance), we had to restart the WebSphere application server as websphere is unable to reconnect to WM Broker. Is there any settings/configuration on websphere or WM broker side to make the Websphere->WM Broker connection establish again without the need of restarting the Websphere application Server?

Hello, We are having similar problem of connections getting lost. We have setup listener using spring framework. webMethods is the JMS Provider. Is there any property setting to this connection active all the time? Issue is sometimes the connection to Broker becomes stale and shows as disconnected in MWS.

Hello, We are having problem of connections getting lost to webMethods broker from a JMS client. Issue is sometimes the connection to Broker becomes stale and shows as disconnected in MWS. We have setup listener using spring framework. webMethods is the JMS Provider. Is there any property setting to keep this connection active all the time?

Anyone found a solution to this problem?

I am also facing the same situation i.e when the Broker got restarted the respective clients are getting disconnected. Sending individuals mails to the clients system to reset the connection. As per my understanding JMS consumer use Java API and SAG supplied JARs to connect to our native broker to receive JMS message. So its basically a class which creates connection object. if that is the case why the client system need to restart the application server? How the implementation will differ from clients to clients? Could some brief how the Client systems are handling the situation?

Is this a Bug in the Product or this is how all the middle product behaves? Could someone answer me for the same!!!

First of all, make sure you have the latest fixes for Broker Core, Java API & JMS API applied.

JMS API additionally needs to be given to the partner system, that they can integrate this in their classpath.

Current Fix Levels:
Broker 7.1.2: Core Fix 17, Java API Fix5, JMS API Fix11
Broker 9.5 SP1: Core Fix4, Java API Fix1 (No JMS API Fix needed atm as this is included in the JavaAPI Fix1)

As I am not working with wM 8.2 atm I am not aware of the resp. Fix Levels.

See the 7-1_Broker_Messaging_Programmers_Guide.pdf or 9-5_Broker_Messaging_Programmers_Guide.pdf
for how to configure KeepAlive and Reconnect-Configuration.

i.e.:

JMS Provider-Specific Properties
In some cases, you may need to set provider?specific properties for the webMethods JMS
Provider to values other than the defaults. The provider?specific properties include
internal provider values such as the timeout value for a connection to the Broker.
1 Create a Java properties file named wmjms.properties.
2 Add the properties that you want to change to that file.
3 Add the file to your CLASSPATH.
The provider?specific properties are defined in the Javadoc of the WmJMSConfig class; use
that information before reconfiguring the property values in your code.

and

To improve the response time for detecting disconnections between a Broker and
a client:
com.webmethods.jms.broker.keepAliveTimeout=30
com.webmethods.jms.broker.keepAliveAttempts=100
com.webmethods.jms.broker.keepAliveInterval=30
com.webmethods.jms.keepAliveInterval=30

Most likely the mentioned properties file needs to be placed on the client side of the connection.

Regards,
Holger

Hi Holger,

Thank you very much for your inputs. As per my understanding from your inputs are given below.

Correct me if i am wrong.

1. From our end, we have to make sure that we are updated with all the core fixes irrespective of the product version.

2. From the client end, they have to make sure that they are using right properties of our jar which we have provided.

If both are good then we can definitely avoid this kind of situation.