cronet-transport-for-okhttp
cronet-transport-for-okhttp copied to clipboard
java.lang.IllegalStateException: There is no read or rewind or length check in progress CronetUploadDataStream
crashes are counted on firebase.
my UploadDataProvider code:
@Override
public void rewind(UploadDataSink uploadDataSink) {
if (LogUtils.isLogEnable()) {
LogUtils.d("cronet", "InMemoryRequestBodyConverter , rewind: "+requestBody.isOneShot());
}
if (requestBody.isOneShot()) {
uploadDataSink.onRewindError(new UnsupportedOperationException("Rewind is not supported!"));
}else{
isMaterialized = false;
materializedBody.clear();
uploadDataSink.onRewindSucceeded();
}
}
Can you please provide the full stacktrace?
just occurs in custom uploadExecutors
Fatal Exception: java.lang.IllegalStateException: There is no read or rewind or length check in progress. at org.chromium.net.impl.CronetUploadDataStream.b(:com.google.android.gms.dynamite_cronetdynamite@[email protected] (170306-0):6) at eq.run(:com.google.android.gms.dynamite_cronetdynamite@[email protected] (170306-0):6) at com.cname.core.threadpool.lib.CommandThreadPoolExecutor.runWorker(:54) at com.cname.core.threadpool.lib.Worker.run(:2) at java.lang.Thread.run(Thread.java:923) at com.cname.core.threadpool.lib.CommandThreadFactory$1.run(:9)
@Danstahrg I'm confused, can this modification avoid this crash? The exception is still thrown and not caught [疑问]
if (mInWhichUserCallback == UserCallback.NOT_IN_CALLBACK) { throw new IllegalStateException( "There is no read or rewind or length check in progress.", exception); }
You're right in that it doesn't solve your issue straight away but as noted in the commit description it allows for more efficient troubleshooting.
If you look through the code in more detail you'll find out that the onError
method that throws the exception is only called from other methods which either check mInWhichUserCallback
value or set it it themselves. As this occurs within onError
method the exception you're seeing is just a symptom of another problem, and seeing the exception that caused it in the first place would help us zoom in in more detail.
As to what the actual problem is, given the above this looks like multiple callback methods being executed concurrently and interfering with each other. It looks like you're using a custom upload data provider - are you reusing instances of it by any chance?
Either way, this looks like an issue unrelated to this shim library - can you open a Chromium bug? Please include the full implementation of your data provider and examples of how you use it.
I used this library, only modified here
the usage is the same as okhttp.