Glad you're unblocked. Please look into using the asynchronous session APIs as 
well.

Way

From: Poole, Gary [mailto:[email protected]]
Sent: Monday, June 20, 2016 8:11 AM
To: Way Vadhanasin <[email protected]>; 
[email protected]
Cc: Cazier, Robb P (CEPS SW Development) <[email protected]>; Blayney, Jeff 
<[email protected]>; Singh, Baljit ((PPS-ASG)) <[email protected]>; 
Mozzetta, Jonathan <[email protected]>
Subject: RE: [Allseen-core] BusAttachment::LeaveHostedSession is causing the 
Windows AJ Router to stop responding

Thanks Way,
We will file a bug on the LeaveHostedSession and attach a dump file. As a 
workaround we will use SetLinkTimeOut, and add logic to tell the client to 
leave the session, and let SessionLost to manage the session instead of calling 
LeaveHostedSession.

We found the issue were Android is suddenly leaving to be part of the logic in 
our code where we disconnect the Android on a AuthenticationComplete failure 
and is not a bug.

--Gary Poole


From: Way Vadhanasin [mailto:[email protected]]
Sent: Thursday, June 16, 2016 1:40 AM
To: Poole, Gary <[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Cc: Cazier, Robb P (CEPS SW Development) 
<[email protected]<mailto:[email protected]>>; Blayney, Jeff 
<[email protected]<mailto:[email protected]>>; Singh, Baljit 
((PPS-ASG)) <[email protected]<mailto:[email protected]>>; Mozzetta, 
Jonathan <[email protected]<mailto:[email protected]>>
Subject: RE: [Allseen-core] BusAttachment::LeaveHostedSession is causing the 
Windows AJ Router to stop responding

Hi Gary,

For your experience on BusAttachment::LeaveHostedSession causing the Windows 
router service to malfunction, do you have a test application I can use to try 
to debug? Better yet, if you're familiar with windbg, please attach the 
debugger to the router service (you can use -p option) while it is in bad state 
and capture the process memory dump (using .dump /mfh memory.dmp command in 
windbg). From glancing at LeaveHostedSession handler, it appears the router is 
doing a lot of things here under lock and it's possible that other I/O's end up 
waiting on the same lock. A full process memory dump would definitely help. 
Also please see if using the asynchronous version of these session APIs make a 
difference.

For early SessionLost issue, you might be hitting a side effect of how AllJoyn 
implements ARDP protocol (over UDP). I believe if a remote RN, connected via 
UDP, isn't responding to the ARDP keep-alive packets fast enough (and this is 
originated by the app's RN), the app's RN would give up and send SessionLost 
notifications to its LNs. Also unlike TCP, the UDP transport makes the app's 
link timeout obsolete since it enforces the bus-to-bus timeouts, which is much 
shorter than the minimum application's link timeout allowed (40s).

For both issues, could you please file Jira 
tickets<https://jira.allseenalliance.org/projects/ASACORE> to track?

Thanks,
Way


From: 
[email protected]<mailto:[email protected]>
 [mailto:[email protected]] On Behalf Of Poole, 
Gary
Sent: Wednesday, June 15, 2016 12:02 PM
To: 
[email protected]<mailto:[email protected]>
Cc: Cazier, Robb P (CEPS SW Development) 
<[email protected]<mailto:[email protected]>>; Blayney, Jeff 
<[email protected]<mailto:[email protected]>>; Singh, Baljit 
((PPS-ASG)) <[email protected]<mailto:[email protected]>>; Mozzetta, 
Jonathan <[email protected]<mailto:[email protected]>>
Subject: [Allseen-core] BusAttachment::LeaveHostedSession is causing the 
Windows AJ Router to stop responding

Hello all,
I need help with 2 issues:

For Windows, the BusAttachment::LeaveHostedSession will sometimes not return 
until a long timeout and put the Windows AllJoyn Router in a bad state (meaning 
the service won't respond to request and we cannot restart that service). This 
could be from a race condition where we tried to leave a hosted SessionId that 
is no longer valid. Because we have not processed the corresponding SessionLost 
yet. We can reproduce this issue if we try to make the same LeaveHostedSession 
on a session where we are a client instead of a host. We have seen this issue 
in 15.09, 15.09a, and 16.04.

We are also seeing a SessionListener::SessionLost for an Android device several 
seconds (about 5) after as session is connected. The frequency for this is 
about 4/6 attempts. We are using SetLinkTimeout for 40 seconds, but we see that 
the SessionLost is much quicker than that. The Android device is using 15.09a 
talking to a 15.09a or 16.04 Windows.

--Gary Poole

_______________________________________________
Allseen-core mailing list
[email protected]
https://lists.allseenalliance.org/mailman/listinfo/allseen-core

Reply via email to