Hi George, Thanks for responding.
There are 2 "layers" of the issue that we discovered, and I would like to share. The #1 problem was the lack of the *context in the OcPlatform * initialization. Android SDK works quite well when you pass 'null' as a Context in PlatformConfig. But seems like the connectivity layer you mentioned needs that Context, in order to listen to network changes and recover. I did not manage to trace all the code, but I definitely saw "network recovery" activities in the traces, since I added the real Context. #2 problem: this improves the situation, but does not solve the issue completely. Indeed, I maanged to reproduce the problem with a small modification of the 'simpleclient Android sample. [Notice that the sample does not suffer from #1, the right Context is used]. The issue is already reported to JIRA: https://jira.iotivity.org/browse/IOT-2947 <https://jira.iotivity.org/browse/IOT-2947> Thanks for care Best regards, Max On Tue, Jan 2, 2018 at 7:27 PM, Nash, George <[email protected]> wrote: > Max this is the first that I have heard this problem. Then again, most of > us don’t end up switching networks so it very likely you have discovered a > new bug. I would encourage creating a Jira ticket for this issue. > > > > If you don’t feel comfortable creating a Jira ticket I can create one from > the information you provided here. > > > > The failure is most likely in the connectivity layer of the IoTivity which > I am unfamiliar with. I hope someone with more expertise in that area will > comment on this post. > > > > George Nash > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Max Kholmyansky > *Sent:* Sunday, December 24, 2017 12:55 PM > *To:* iotivity <[email protected]> > *Subject:* [dev] Multicast discovery failure (usually after WiFi netwrok > switches) > > > > Hi, > > > > I am using IoTivity 1.3.1 in Android client (Java SDK) > > > > From time to time, the client stops discovering the servers over the > network. > > Technically, in a failure after findResources() is called with "/oic/res", > the error callback "onFindResourceErrorCallback" is called, and no > resources are discovered. > > > > A typical failure scenario: > > - Client is connected to WiFi "Network1". > - Resource discover works fine. > - Connect the client to another WiFi network ("Network2") for few > seconds. Then back to "Network1". > - From that point, usually, findResources() starts failing, although > the server logs indicate that they respond normally. > - Usually, after turning WiFi off for a while, and then turning on and > reconnecting to "Network1" - all starts working normally again. > > I was able to reproduce this issue with "simpleclient" sample, by changing > the discovery query from "/oic/res?rt=core.light" to "/oic/res". > > > > Attaching the IoTivity trace. > > > > Anyone can find an indication of a specific problem in the log? > > > > 2 specific issues that I noticed. > > > > 1. There is always a line in the logs: > > D/OIC_CA_MSG_HANDLE: error callback error: 7 > > Looking in IoTivity headers: "7" is > > CA_SEND_FAILED, */**< Send request failed */* > > Looks like send over a socket is failing. Is it a familiar problem. > > > > 2. I was able to reproduce the issue only with "/oic/res". > > When trying to discover a specific resource type, like "/oic/res?rt=oic.wk.d" > - I did not get to the stack error. > > Is there any essential difference between how the discovery with and without > filters are handled? > > > > > > Thanks for any hint > > Max > > > > > > > > > > >
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
