Hello Ruwan, thank you very much for your detailed answers which really provides good starting points for further investigation. We will take that, go ahead and make some tests. As questions arise, we sure will ask again.
Please see inline for further comments and questions! > > - Which of these requirements are covered with the current > > implementation and which are not? > mediator to collect response time and stuff like that. At the same time > it will be effective to use a custom comprehensive log mediator to > tackle this requirement because there is a considerable amount of data > per record. Yeah, that was also my initial thought. > > - How can we improve the current implementation to meet these > > requirements? Where shall one start? > We will need to add the message arrival time as a message context > property so that the custom log mediator can retrieve that information. > (Because we cannot consider the logging time as the message arrival time > on a time critical system). We had a similar requirement and I think it > is worth to add this information on receiving a message to synapse. Also > the response time handling has to be a little tricky if you require to > find the difference between message receiving time and the response > message out time. Does this mean you will consider adding the time of message arrival to the message context in the synapse implementation itself in an upcoming version? Now we have to simply set some property at the very beginning on our own, right? > We have a DBReportMediator which is designed for reporting purposes and > that can be used for the database logs and the asynchronous nature can > be achieved by using a clone mediator to clone the message and give it > for logging while the send mediator sends the message out. Ah, the idea of the clone mediator sounds interesting. What about big messages? Might that be an overhead which one would like to avoid? Is it possible to duplicate only parts of the message, e.g. the header? But anyhow the requests shouldn't be that big. Cloning responses might much more be a problem. > > - Is it possible to use only one record for a request/response pair (do > > an insert in the incoming sequence and an update in the outgoing > > sequence)? How to identify a message uniquely in a cluster environment? > > > Even in a cluster environment the response should be coming to the same > server which served the request and the correlation between these two > messages are built into synapse, in other words, you can access the > incoming message properties inside the out going (response) message. Yeah, but logging all information only from the response message implies the risk to loose some may be valuable information if the instance crashes during request processing - or am I wrong? It would be more save to log the request information as early as possible to a persistent store. But then you need to identify the record in order to update it. How to identify this record? This was my question. Of course logging only at response time I wouldn't have such a problem. > Lets get started and will provide the necessary information while you > encounter any issues, and we are willing to give our full support on > getting these information to your mediator, also if there are any issue > in retrieving information that you required, you can file a JIRA for > that and we can get them fixed. > Within your custom mediator you may need to check whether the current > message is incoming or outgoing by checking the > messageContext.isResponse() and insert a record if it is an incoming > message and update the record with relevant information if it is out > going message. This way you can avoid having two implementations for the > in and out message logging. Ah, thanks fort hat hint! But I still have the question how to uniquely identify my log entry. I can't rely on a database generated key, as I don't want "to wait" for the database operation (not even a sequence-call). Again thanks for your valuable feedback! Regards, Eric _______________________________________________ Esb-java-user mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
