First off some background info

My company has a software as a service model where people log onto our servers and do work. In order to support that application we have a utility application that lives on the client machine, and copies binary data from our servers to their machines.

The first iteration of this software polled the database and then generated the information on the client side. This approach was done away with because we thought there where some fundamental flaws

  • Polling the database to see if any work had to be done
  • Opening up our SQL port to the world
  • Pulling all the data from the database and generating it on the client side.

Our second iteration of the software generated the data on one of our servers and sent it on to the client via the Java Messaging Service. The advantages being seen as

  • Event Driven
  • No polling
  • SQL port is closed
  • Data is not being generated over the WAN

The above is to illustrate the approaches we've used in the past.

The problem that we have is that our clients often have poor connectivity to us (packet loss, poor response times etc) JMS was supposed to handle that as it should reconnect when the line comes back up but this doesn't always happen.

What are the best approaches to deal with poor client connectivity?


To explain what I mean about JMS not working as expected.

My expectation of JMS is that it works reliably. What I mean by this is that if a line goes down, or is losing packets, or misbehaving in any other manner that the JMS implementation will continue to try send the message until it succeeds.

As an example I see on an almost daily basis a JMS queue with consumers attached, yet no messages being sent or received, restarting the client normally resolves the issue.

I can speak about more specifics, however for the sake of this conversation lets leave JMS out as potential answer


I wanted some other possible solutions to my problem, but the general consensus seems to be that my current one (JMS) is the best.

So here are 2 of my current cases where I am having issues with JMS

Case 1

Client connects to the queue succesfully sends and receives multiple messages, after a variable time (between several hours and several days) the client no longer receives any messages. The main queue shows the consumers connected, but the client never receives the messages. The resolution is to restart the client application

Case 2

The client never connects to the queue. The client continually tries to reconnect but the reconnection always fails. The resolution for this is to try again in a few hours

Our setup is fairly simple

  • One public server
  • OpenMQ
  • The clients are low volume, ranging from 10 messages a day to a 1000 messages a day
  • Clients never initiate a 'message conversation', the queue initates and the clients reply
  • Messages are small, all pure text, no binary data
  • config is as follows:

    connectionFactory = new ConnectionFactory();
    connectionFactory.setProperty(ConnectionConfiguration.imqAddressList, connectionURL);
    connectionFactory.setProperty(ConnectionConfiguration.imqReconnectEnabled, "true");
    connectionFactory.setProperty(ConnectionConfiguration.imqPingInterval, "30");
    connectionFactory.setProperty(ConnectionConfiguration.imqReconnectAttempts, "-1");
    connectionFactory.setProperty(ConnectionConfiguration.imqReconnectInterval, "30000");
  • "this doesn't always happen"? What does this mean? What's really going on? What did you expect? What did you build? What tests have you run? What failure modes are you observing?
    – S.Lott
    Apr 19, 2011 at 11:23
  • @S.Lott my trials and tribulations with JMS are a story in itself, for simplicities sake I'd just prefer to leave it out as a possible solution
    – Tim Sparg
    Apr 19, 2011 at 12:45
  • @Tim Sparg: Without specific problems, issues, errors or diagnostic information, we can only guess randomly at potential things you haven't already tried.
    – S.Lott
    Apr 19, 2011 at 12:47
  • 1
    @Tim Sparg: I don't get what you're asking for. JMS is the right technology for this problem for the exact reasons you listed in your question. If JMS is not working, then you have a problem with JMS. If you're weary of documenting the problems with JMS, that's odd. You provided excellent reasons for using JMS. What's wrong with JMS as a solution? It sounds like misconfiguration or mismanagement with JMS.
    – S.Lott
    Apr 19, 2011 at 15:32
  • 1
    @Tim Sparg: If the client flakes out, you have client problems. Not JMS problems.
    – S.Lott
    Apr 21, 2011 at 22:11

1 Answer 1


RESTful. JAX-WS supports it.

...In the web services world, REpresentational State Transfer (REST) is a key design idiom that embraces a stateless client-server architecture in which the web services are viewed as resources and can be identified by their URLs. Web service clients that want to use these resources access a particular representation by transferring application content using a small globally defined set of remote methods that describe the action to be performed on the resource. REST is an analytical description of the existing web architecture, and thus the interplay between the style and the underlying HTTP protocol appears seamless...

Architects and developers need to decide when this particular style is an appropriate choice for their applications. A RESTFul design may be appropriate when...


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.