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:
- service gets request service
- prepares data in logdata
- object service calls database
- time taken db interaction captured in logdata object
- service ready send response
- logdata object sent messaging destination
- 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
Post a Comment