Hi, Thanks to all for the clarifications. Still trying to understand how to prevent the leak, from the application programmer's perspective.
Abhishek, when you quote the comnent: * When the next notification comes in from server, * reply with RESET message to server. - I understand that this should be done by the "infrastructure", not by the application programmer, right? So the application programmer needs to call "cancelObserve" and wait for the next resource update for the server to free the registration? Unfortunately, the Simulator Server resources aren't freed, not immediately and not following next update of the resource attributes (just tried) The observers stay "forever" in the list shown in the Simulator GUI. So I am afraid there is still an IoTivity issue hiding here. Regards Max On Thu, Sep 15, 2016 at 4:43 PM, Abhishek Sharma <ce.abhishek at samsung.com> wrote: > > I believe, this issue (or feature) boils down all the way to CSDK where > cancel request is not sent with low QoS. > > Correct. In csdk a cancel observe request is not sent to Server. Rather it > waits for next notification from server and responds with a RESET. > > Check this comment in OCCancel(): > > * 1. qos == OC_NON_CONFIRMABLE. When observe is unobserved.. > * Remove the callback associated on client side. > * When the next notification comes in from server, > * reply with RESET message to server. > * Keep in mind that the server will react to RESET only > * if the last notification was sent as CON > > > > One possible reason could be that in CoAP terms a cancel observe request > is just another GET request without OBSERVE header option. > > Which will add extra overhead of network packet which the server will have > to process and respond to, while it was never really gonna send any > notification or could be sleeping. > > This also means that its not a leak but delayed free. > > y > > > > --------- *Original Message* --------- > > *Sender* : Max Kholmyansky <max001 at gmail.com> > > *Date* : 2016-09-15 18:23 (GMT+5:30) > > *Title* : Re: [dev] Java API 1.1.1 - bug (server resource leak) in > cancelObserve method > > > Tim Hi > > Thanks a lot for your suggestion. > Indeed, High QoS solves the issue. > > Still from my perspective it looks like a bug: choice of QoS should not > cause "leaks" on the server side. > > Best regards, > > > > On Wed, Sep 14, 2016 at 1:55 AM, Kourt, Tim A <tim.a.kourt at intel.com> > wrote: > >> Hi Max, >> >> >> >> Try setting platform?s quality of service to high: >> >> >> >> PlatformConfig platformConfig = new PlatformConfig( >> >> . >> >> . >> >> *QualityOfService.High* >> >> ); >> >> >> >> I believe, this issue (or feature) boils down all the way to CSDK where >> cancel request is not sent with low QoS. >> >> >> >> Best regards, >> >> >> >> Tim Kourt >> >> Intel Open Source Technology Center >> >> >> >> >> >> >> >> *From:* iotivity-dev-bounces at lists.iotivity.org [mailto: >> iotivity-dev-bounces at lists.iotivity.org] *On Behalf Of *Max Kholmyansky >> *Sent:* Tuesday, September 13, 2016 4:08 AM >> *To:* iotivity-dev at lists.iotivity.org >> *Subject:* [dev] Java API 1.1.1 - bug (server resource leak) in >> cancelObserve method >> >> >> >> Hi, >> >> >> >> I am using the Java API (client) of IoTivity 1.1.1 on Android. >> >> >> >> I have a suspicion that *cancelObserve* method of *OcResource* class has >> a "leak": it does not release the observer on the server side. >> >> >> >> My code is quite simple: >> >> - resource.observe(..., ..., ...) >> - // Start getting notifications... >> - resource.cancelObserve() >> - // No notifications, but there is a leak... >> >> The way I detect it - I discover a resource exposed by IoTivity Simulator. >> >> >> >> After a call to cancelObserve() - the observer is staying in the >> "Resource Observers" tab in the Simulator server GUI. >> >> >> >> Simulator client works cleaner: upon "Stop Observe" in the Simulator >> client - the observer is removed from the GUI, and there is a log message >> in the server: Observer removed [id:..., address: ... port: ...]. >> >> >> >> Is it a known bug? Any idea how it can be avoided? >> >> >> >> Thanks and best regards, >> >> >> >> Max. >> >> >> >> Software Architect - Tekoia Ltd. >> > > _______________________________________________ > iotivity-dev mailing listiotivity-dev at > lists.iotivity.orghttps://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160915/73f1ad25/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13402 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160915/73f1ad25/attachment.gif>
