Inconsistency count logic in RedisRegistrationStore.getAllRegistrations() and RedisRegistrationStore.Cleaner. #401
Comments
|
btw, i also see this. somehow in that second, the device is unregistered and registered ... 2017-10-06 18:58:05 INFO RegistrationLogger - Device, TCMR-10000002, just unregistered ... 2017-10-06 18:58:12 INFO RegistrationLogger - Device, TCMR-1234567, just updated TCMR-1234567's registration ... |
|
2017-10-06 19:15:19 INFO RegistrationLogger - Device, TCMR-10000099, just updated TCMR-10000099's registration ... 2017-10-06 19:15:59 INFO RegistrationLogger - Device, TCMR-10000099, just registered ... |
I re-look at this and it seems ok for me.
This is the more stable class of this experimental package ;)
I made some minor modification in #402, you should try if this behave better. LeshanServerBuilder builder = new LeshanServerBuilder();
builder.setRegistrationStore(new RedisRegistrationStore(jedis, RedisRegistrationStore.DEFAULT_CLEAN_PERIOD,
93/* seconds => MAX_TRANSMITWAIT */));
}
// Create and start LWM2M server
LeshanServer lwServer = builder.build();Please try without this clemency feature before. |
|
Thanks :) |
|
Any news ? |
|
Some of my co-worker thinks maybe due to the thread pool size from leshan. Thx :) |
|
In Leshan we try to enhance that and do our best to send the request after sending the response (see #249) Anyway, A client should be able to handle this kind of bad ordering because of UDP (as I explained here : #388 (comment) ) |
|
My solution was to do it through LESHAN_REQ channel, not through listeners. I feel the code is cleaner. For #249 you mentioned above, Same for the response ? the response refers to the response from registration or registration update ? By the way, I am a little confused about what you said there. Here, "It" means device and what "LWM2M response" is sent by device here ? Why "It" goes after "LWM2M response" ? Isn't the registration event always going first ? "It aims to send registration event (register, update, deregister) after we effectively send the LWM2M response" One more question, what is the future of Q mode for leshan ? |
You feel wrong and you will face some issue later like missing features because as I said this is not our priority.
Before #249, event (RegistrationListener callback) was execute before the response of register/update/deregister request was sent. Generally user want to send downlink request (write/read/ ...) to client on this event. If you do that synchronously there was lot of change that your request was sent before the register/update/deregister response. #249 limit this issue. But again this is just an optimization because of udp reordering. (see eclipse-wakaama/wakaama#24 (comment)) If you device does not handle that correctly, just add a delay before to send your downlink request.
For now, unless somebody work again on #265, Q mode will probably not be implemented in the v1.0.0. |
|
Hi Sbernard31, If Q mode is done by myself (on top of leshan server), However, you seemed to say LESHAN_REQ is in experimental stage. Thanks :) |
|
You should use : LeshanServer.send(Registration destination, DownlinkRequest<T> request,
ResponseCallback<T> responseCallback, ErrorCallback errorCallback) |
|
Thanks :) |
Hi sbernard31,
Remembered your fix for the following.
#393
I took a look at the logic for cleaner.
They look different in its implementation.
Could you take a look at the count logic in Cleaner to see it is correct ?
The reason why I asked is because I keep seeing the following in my log.
Somehow, the device seems to be unregistered by Cleaner, but the device was still alive ... but the server seems not be able to listen to it ...
8115978 [CoapServer#4] INFO com.sandc.enterprise.ts2c.leshan.dm.listener.RegistrationLogger - Device, TCMR-1000001, just updated TCMR-1000001's registration ...
8133873 [CoapServer#1] INFO com.sandc.enterprise.ts2c.leshan.dm.listener.RegistrationLogger - Device, TCMR-09999999, just updated TCMR-09999999's registration ...
8162233 [RedisRegistrationStore Cleaner (60s)] INFO com.sandc.enterprise.ts2c.leshan.dm.listener.RegistrationLogger - Device, TCMR-1000001, just unregistered ...
Thanks :)
The text was updated successfully, but these errors were encountered: