[db023/Android 5.1.1 (API 22)] InputDispatcher: .MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
See original GitHub issueLibrary Version
Both CouchbaseLite/2.0.0 (.NET; Android 5.1.1 [API 22]; LGE Nexus 4) Build/636 LiteCore/732 Commit/c18ebea and own build: CouchbaseLite/0.0.0 (.NET; Android 5.1.1 [API 22]; LGE Nexus 4) Build/0 LiteCore/732 Commit/b415d08
.NET Runtime
(Microsoft Visual Studio Enterprise 2017 Version 15.6.3) Xamarin.Android SDK 8.2.0.16 (HEAD/a78295902)
Operating System
Windows 10 enterprise version 1709
Log Output
Expected behavior
Replication of all buckets
Actual behavior
App crashes without any notice on screen or in debug in the middle of a bucket replication. The first buckets with a low amount of and simple structured documents seem to do fine. Problem occurs always with high amount of documents (500+) and sometimes with complex structured documents (see example in attached files)
Only hint is
03-22 10:51:06.945: W/InputDispatcher(556): channel '22c874bd com.companyname.ReplicationTest/md584f0757e160eb302f61ea570c782d337.MainActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x9
03-22 10:51:06.945: E/InputDispatcher(556): channel '22c874bd com.companyname.ReplicationTest/md584f0757e160eb302f61ea570c782d337.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
Could indicate too much threads
Steps To Reproduce
- Start application
- Begin replication of one bucket
- When the current finishes start the next bucketreplication. (indicator:
completed == total and status == stopped
Reproduction Project
Encrypted. Simplification. Renamed from .zip.pgp to .zip for upload purposes ReplicationTest.zip
Issue Analytics
- State:
- Created 5 years ago
- Comments:12 (7 by maintainers)
With regards to freezing at busy, I have a better handle on some of the causes of that now. I’ve been working with Xamarin Android to find out exactly what happens when things go offline and it’s a different socket error than other .NET platforms so including that in the list of transient errors to recognize helped out, as well as detecting repeated inability to read from the remote stream as a closure (otherwise it was an infinite loop basically…). This solves some of the more common stuck busy cases I’ve faced with Xamarin.
We will probably put out some kind of 2.1 preview soon (DB, beta, or otherwise since we have only about 2 months total to ship including all dev and testing) and I think the Xamarin story will be a lot better (not to mention we are still on track to incorporating Xamarin builds into the functional test suite that we have). I’d be curious to see what effect this has on this.
Hi @borrrden
We only test on devices, not on emulators. So I don’t really know if the problem holds on emulators. As I said before it could just be my device. It’s already a good 5 years old. Oldtimer in techtime 😃