[Feature Request] Ability to monitor request-response lifecycle

[Nick-The-Uncharted]

Question

Currently we have org.eclipse.californium.core.network.interceptors.MessageInterceptor which can be called when request is received or when response is sent, but we can not pair them. Upon sendResponse callback we only have response as parameter, but we don't know it is response of which request, especially we don't know when the request is arrived. So we are having trouble implementing something like slow logs or performance monitors.

If we have Exchange as a parameter of those callbacks, things will be a lot easier.

[sbernard31]

For completeness :

I add content of your previous comment here :

During performance test, we surely need something like access-log to easily figure out problems.

Some problems I have met so far:

1. Frequent gc leading to registration update time out. (our elb can only keep udp session for 10s, time out means offline).
2. We send msg to kafka synchronously, and one day kakfa has heavy load so it response slow (5ms), which leading to CoapServer thread blocked and unable to process registration update in time.

If I am able to provide a UplinkRequestReceiver of my own, access log can be easily implemented.

And also the link to an existing related issue : https://github.com/eclipse-leshan/leshan/issues/696

[sbernard31]

First note that a LWM2M request or response could means several CoAP request. (e.g. when using blockwise transfer) This is also true for response.

Then, do you want to monitor LWM2M request or CoAP request ?

• If you want to monitor LWM2M request we can try think about a new API to do that.
• If you want to monitor CoAP request, you need to deal with org.eclipse.californium.core.network.interceptors.MessageInterceptor but this is a Californium class, so if modification is needed better to ask to Californium project.

Currently we have org.eclipse.californium.core.network.interceptors.MessageInterceptor which can be called when request is received or when response is sent, but we can not pair them. Upon sendResponse callback we only have response as parameter, but we don't know it is response of which request, especially we don't know when the request is arrived.

A possible working solution. Store time in map with (Token + Identity) as key on receiveRequest and in Response you should also find Token+Identity.

[Nick-The-Uncharted]

@sbernard31 Sorry for the late response, I got overrun by my work.

I want to monitor lwm2m request, I am using org.eclipse.californium.core.network.interceptors.MessageInterceptor only because currently there is no api to monitor lwm2m request.

I used Store time in map with (Token + Identity) as key to implement this feature, but I want to ignore registerUpdateRequest, this become very complex to implement (I can never know the parameter of sendResponse is the resposne of what request).

[sbernard31]

Sorry for the late response, I got overrun by my work.

No Problem.

I want to monitor lwm2m request, I am using org.eclipse.californium.core.network.interceptors.MessageInterceptor only because currently there is no api to monitor lwm2m request.

Got it. I keep this in mind and will try to work on that when I found time.

I used Store time in map with (Token + Identity) as key to implement this feature, but I want to ignore registerUpdateRequest, this become very complex to implement (I can never know the parameter of sendResponse is the resposne of what request).

I understand but you must deal with MessageInterceptor waiting I work on :point_up: .

Update request are POST with uri.size == 2 and first part of the uri = rd. (see RegisterResource)

I can never know the parameter of sendResponse is the resposne of what request

I don't get this :thinking:

[Nick-The-Uncharted]

I can never know the parameter of sendResponse is the resposne of what request

Because we try to log request handling time, so we do that in the callback of org.eclipse.californium.core.network.interceptors.MessageInterceptor#sendResponse, but that method only have one parameter response, there is no easy way to get the corresponding request.

[sbernard31]

@Nick-The-Uncharted does #1617 could solve your problem ? Let me know.

[Nick-The-Uncharted]

@sbernard31 Yes, this perfectly solved my problem, thanks a lot

[sbernard31]

@Nick-The-Uncharted, #1617 is now integrated in master. It should be available in 2.0.0-M15. (#1612)

[sbernard31]

@Nick-The-Uncharted Thx to you for taking time to provide feedback to make Leshan better. :wink: