Distributed JMS based logging .. falling flat?

Question

In our fancy ESB, logging of each request is done via a common infrastructure based on JMS based logging. Here is what happens in a nutshell:
service gets a request service
prepares some data in a LogData
object service calls database
time taken for db interaction is captured in LogData object
service is ready to send response
LogData object is sent to a messaging destination
service sends response
Very rosey! yes for paper architects. Here is the actual issue: The JMS service provider sometimes becomes unavailable - due to a system level error or the software crashes. Then the service waits at the step (step no. 6) where it has to make JMS connection to send LogData object. Resulting in delayed response, thus leading to bad performance and user experience.
So that is the biggest shortcoming of "Distributed logging using JMS" touted by a lot of developer websites. Also note that the presance of LogData is kind of critical non-functional requirement. That means the messages are sent in persistent mode, leading to a wait until the JMS provider confirms receipt of message to the sender (the service in this case) - what to be blamed? immature design? Are there any success stories of implementing something like this?

Answer 1

user13559021 wrote:
In our fancy ESB, logging of each request is done via a common infrastructure based on JMS based logging. Here is what happens in a nutshell:
service gets a request service
prepares some data in a LogData
object service calls database
time taken for db interaction is captured in LogData object
service is ready to send response
LogData object is sent to a messaging destination
service sends response
Very rosey! yes for paper architects. Here is the actual issue: The JMS service provider sometimes becomes unavailable - due to a system level error or the software crashes. Then the service waits at the step (step no. 6) where it has to make JMS connection to send LogData object. Resulting in delayed response, thus leading to bad performance and user experience.
So that is the biggest shortcoming of "Distributed logging using JMS" touted by a lot of developer websites. Also note that the presance of LogData is kind of critical non-functional requirement. That means the messages are sent in persistent mode, leading to a wait until the JMS provider confirms receipt of message to the sender (the service in this case) - what to be blamed? immature design? Are there any success stories of implementing something like this?I don't understand what this has to do with JMS.
You can substitute 'database', 'web service' or 'jboss' (as examples) in the above and change nothing.
If you have a remote server that is a required part of your processing system in a 24x7 system then you must come to some understanding of both what is allowed when the service is not available at all and what is allowed when there are intermittent outages.
The first must be considered because something like a router going done can take quite a while to diagnose and replace.
Besides the solution noted above I have also implemented a solution that cause my service to stop accepting any transactions at all if the secondary processors cannot respond in a timely manner. The reasoning there is that in planned for volume scenarios it is possible for several thousand transactions to be backed up even in the best circumstances in a couple of seconds, thus taking more in could result in a large number of failures.
Additionally back end systems might run via a load balancer. That however can still have failure scenarios, again for example when a router goes out, or when one balanced server accepts a connection but fails to process it.