Hi Eric,
Hubert, Eric wrote:
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!
OK, see my answers...
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?
Yes, for that we have implemented a sequence named "pre-mediate" in the
SNAPSHOT (nightly) build which will be called before any mediation as
soon as the message arrives in to synapse regardless of whether this
particular message is for a proxy service or not. You can use this
sequence to set initial properties, well you could get the current time
by using the get-property('SYSTEM_DATE') xpath extension function. But I
think message arrival time can added from synapse core it self to the
message context.
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.
Not for the moment, it just clones the full message. So it can be an
overhead. May be we can improve the clone mediator for that or else we
can implement a simple clone mediator for that.
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.
As I told you the response contains all the message properties of the
request so that you can find the correlation by setting the message id
of the request as a property in to the request message itself with a
name like "CORRELATION", which will be available for the response as
well and you can insert the records with that message id as the key on
the request logging. So on the response you can update the record with
that key which can be obtained from the message context as a property.
This key doesn't has to be the message id, you can use what ever unique
id you what but that has to be set to the message context as a property
in-order to retrieve that on the response side.
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).
I think the above answer provides the answer for this question.
Thanks,
Ruwan
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
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
