java - Distributed JMS based logging .. falling flat? -


in our fancy esb, logging of each request done via common infrastructure based on jms based logging. here happens in nutshell:

  1. service gets request service
  2. prepares data in logdata
  3. object service calls database
  4. time taken db interaction captured in logdata object
  5. service ready send response
  6. logdata object sent messaging destination
  7. service sends response

very rosey! yes paper architects. here actual issue: jms service provider becomes unavailable - due system level error or software crashes. service waits @ step (step no. 6) has make jms connection send logdata object. resulting in delayed response, leading bad performance , user experience.

so biggest shortcoming of "distributed logging using jms" touted lot of developer websites. note presance of logdata kind of critical non-functional requirement. means messages sent in persistent mode, leading wait until jms provider confirms receipt of message sender (the service in case) - blamed? immature design? are there success stories of implementing this?

doing logging in db/jms/socket/etc synchronously asking problems , lot of them.

implement logging memory , async. dump file/jms (depending if jms becomes available). single background thread should trick you. having sync. logging cause lot of trouble in totally unexpected , innocent portions of application.

i can't think of possible success story of sync. logging.

edit. preferrably use of concurrentlinkedqueue keep logdata (i mean avoid blocking, if possible improve perforamce/throughput)


Comments

Popular posts from this blog

linux - Mailx and Gmail nss config dir -

c# - Is it possible to remove an existing registration from Autofac container builder? -

php - Mysql PK and FK char(36) vs int(10) -