Memory isn't released after uploading large file and perfrom other actions on storage

Hi,
The main issue when uploading large files.the memory still exist after transfer completed successfully.
Every action I am trying to perfrom against azure storage increase the memory but when I finish the memory doesn't released.
The memory in the java process doesn't decrease.
Should I clear any resources?
I am creating blobServiceClient the memory increased,listContinaer memory is increases,upload file memory is increased.
Looks like garbage collector doesn't release those objects or there is memory leak in the code.
Only when I perfrom System.gc() manually it sometimes release the memory but most of the time the memory is remains very big.
Is there anything to do in order to decrease the java memory
Thanks,
Itay

Hi @rickle-msft
Could you please help?
Thanks,
Itay

Hi @ihudedi
Thank you for posting this issue. Could you provide a short code snippet so we can reproduce this issue on our end?

Hi @ihudedi
Thank you for posting this issue. Could you provide a short code snippet so we can reproduce this issue on our end?

Hi @gapra-msft
Try uploading large file via bloboutputstream and when it finished upliading the memory increased and released after a lot of time or when running manually System.gc()
Thanks,
Itay

Hi @gapra-msft
Try uploading large file via bloboutputstream and when it finished upliading the memory increased and released after a lot of time or when running manually System.gc()
Thanks,
Itay

ParallelTransferOptions parallelTransferOptions = new ParallelTransferOptions();
//Maybe need to change those settings
int azureBlockUploadSize = 4194304;
int azureMaxSingleUploadSize = 4194304;
int azureMaxUploadConcurrency = 8;
boolean azureDisplayUploadProgress = true;
            parallelTransferOptions.setBlockSizeLong(Long.valueOf(azureBlockUploadSize));

            parallelTransferOptions.setMaxSingleUploadSizeLong(Long.valueOf(azureMaxSingleUploadSize));

            parallelTransferOptions.setMaxConcurrency(azureMaxUploadConcurrency);

            parallelTransferOptions.setProgressReceiver(new AzureProgressReceiver(azureFileCopy));

        blockBlobOutputStreamOptions.setParallelTransferOptions(parallelTransferOptions);

try (OutputStream outputStream =blobClient.getBlockBlobClient().getBlobOutputStream(blockBlobOutputStreamOptions){
bytesRead = -1;
byte[] bytesArray = new byte[jobUtilities.getBufferSize()];
while (!isInteruppted() && ((bytesRead = inputStream.read(bytesArray)) != -1)) {
outputStream.write(bytesArray, 0, bytesRead);
}
}

ParallelTransferOptions parallelTransferOptions = new ParallelTransferOptions();
//Maybe need to change those settings
int azureBlockUploadSize = 4194304;
int azureMaxSingleUploadSize = 4194304;
int azureMaxUploadConcurrency = 8;
boolean azureDisplayUploadProgress = true;
            parallelTransferOptions.setBlockSizeLong(Long.valueOf(azureBlockUploadSize));

            parallelTransferOptions.setMaxSingleUploadSizeLong(Long.valueOf(azureMaxSingleUploadSize));

            parallelTransferOptions.setMaxConcurrency(azureMaxUploadConcurrency);

            parallelTransferOptions.setProgressReceiver(new AzureProgressReceiver(azureFileCopy));

        blockBlobOutputStreamOptions.setParallelTransferOptions(parallelTransferOptions);

try (OutputStream outputStream =blobClient.getBlockBlobClient().getBlobOutputStream(blockBlobOutputStreamOptions){
bytesRead = -1;
byte[] bytesArray = new byte[jobUtilities.getBufferSize()];
while (!isInteruppted() && ((bytesRead = inputStream.read(bytesArray)) != -1)) {
outputStream.write(bytesArray, 0, bytesRead);
}
}

@ihudedi I'm looking into our upload paths and taking stock of any memory allocations today to see if we can reduce that count.
As for the memory lasting "a long time", though, we aren't directly in control of that for memory allocated by the sdk. I'll double check this, but no buffers are held by the sdk beyond the duration of an api call; at the very longest, a buffer is created and held for the duration of an upload operation and then all references to it are dropped. If the memory is still present on the heap, that is really up to the jvm. I believe there are jvm options for more aggressive garbage collection, but we can't force that memory to be reclaimed other than ensuring we don't hold a reference to it.
We do use netty for our transport layer, and netty by default has some buffer pooling logic, which allocates direct buffers instead of buffers on the heap. This memory is not subject to garbage collection and is internally managed by netty. It could be this pooling that you are seeing. You might try configuring it using the following environment variables to see how it affects your applications:
-Dio.netty.noPreferDirect: false // Prevents use of direct buffers in favor of heap buffers
-Dio.netty.maxDirectMemory: -1 bytes // Explicit set for the maximum direct memory, otherwise an inferred amount is used

@ihudedi I'm looking into our upload paths and taking stock of any memory allocations today to see if we can reduce that count.
As for the memory lasting "a long time", though, we aren't directly in control of that for memory allocated by the sdk. I'll double check this, but no buffers are held by the sdk beyond the duration of an api call; at the very longest, a buffer is created and held for the duration of an upload operation and then all references to it are dropped. If the memory is still present on the heap, that is really up to the jvm. I believe there are jvm options for more aggressive garbage collection, but we can't force that memory to be reclaimed other than ensuring we don't hold a reference to it.
We do use netty for our transport layer, and netty by default has some buffer pooling logic, which allocates direct buffers instead of buffers on the heap. This memory is not subject to garbage collection and is internally managed by netty. It could be this pooling that you are seeing. You might try configuring it using the following environment variables to see how it affects your applications:
-Dio.netty.noPreferDirect: false // Prevents use of direct buffers in favor of heap buffers
-Dio.netty.maxDirectMemory: -1 bytes // Explicit set for the maximum direct memory, otherwise an inferred amount is used

Hi @rickle-msft
The defaullt value for io.netty.noPreferDirect is false
and for io.netty.maxDirectMemory=-1
So why should I need to set them?
Thanks,
Itay

Hi @rickle-msft
The defaullt value for io.netty.noPreferDirect is false
and for io.netty.maxDirectMemory=-1
So why should I need to set them?
Thanks,
Itay

This would just be an experiment which may help. If changing these values affects your observed memory consumption, then it'll indicate that the problem you're seeing lies more in the netty layer than in the sdk layer.
I think setting noPreferDirect=true will move its memory pooling onto the heap, which could mean that gc's will be more effective on reducing memory.
Alternatively, with noPreferDirect=true and setting the maxDirectMemory value to some smaller constraint, we might see that the memory usage is capped at around the value you set.

This would just be an experiment which may help. If changing these values affects your observed memory consumption, then it'll indicate that the problem you're seeing lies more in the netty layer than in the sdk layer.
I think setting noPreferDirect=true will move its memory pooling onto the heap, which could mean that gc's will be more effective on reducing memory.
Alternatively, with noPreferDirect=true and setting the maxDirectMemory value to some smaller constraint, we might see that the memory usage is capped at around the value you set.

I've done some investigation into our buffering, and I think there is at least one I can get rid of for the upload() cases, but because of #18314 we will likely have to introduce another copy into the BlockBlobOutputStream which means it will likely remain about the same performance as it is now.

I've done some investigation into our buffering, and I think there is at least one I can get rid of for the upload() cases, but because of #18314 we will likely have to introduce another copy into the BlockBlobOutputStream which means it will likely remain about the same performance as it is now.

Hi @rickle-msft
I set
-Dio.netty.noPreferDirect=true
-Dio.netty.maxDirectMemory=0
Don;t see any change.
After any call the memory increased and it take much time to reduce and sometimes after perform System.gc()
Is the param -XX:MaxDirectMemorySize will help me or increase the memory?
Thanks,
Itay

Hi @rickle-msft
I set
-Dio.netty.noPreferDirect=true
-Dio.netty.maxDirectMemory=0
Don;t see any change.
After any call the memory increased and it take much time to reduce and sometimes after perform System.gc()
Is the param -XX:MaxDirectMemorySize will help me or increase the memory?
Thanks,
Itay

I'm still learning about these parameters myself, but I would try a small-ish value and a large-ish value and see what you get.
How are you monitoring your memory usage? And can you share any data or visualization you have? Looking again at your original post, it doesn't quite make sense to me that you would see a large, lingering spike in memory when you create a blobServiceClient as clients are very lightweight objects.

I'm still learning about these parameters myself, but I would try a small-ish value and a large-ish value and see what you get.
How are you monitoring your memory usage? And can you share any data or visualization you have? Looking again at your original post, it doesn't quite make sense to me that you would see a large, lingering spike in memory when you create a blobServiceClient as clients are very lightweight objects.

Hi @rickle-msft
In java application when create blobServiceClient and try to get listContainer the memory of the process increses in 150MB
I see in task manager all the time.
Thanks,
Itay

Hi @rickle-msft
In java application when create blobServiceClient and try to get listContainer the memory of the process increses in 150MB
I see in task manager all the time.
Thanks,
Itay

Does it increase 150MB each time you list so the usage keeps climbing with each listing operation? Or just once and then it stays at 150MB?

Does it increase 150MB each time you list so the usage keeps climbing with each listing operation? Or just once and then it stays at 150MB?

Hi @rickle-msft
For listcontainer it increase only in first time.but not decreased.when I uploading 10 files of 50MB the memory increase in 500MB.I can arrive to 1.5 GB memory after uploading 20 files of 50MB.The worst the memory doesn't released even after much time.only some system.gc call after time to time can reduce the memory but not to the original size.my application can send numerous files simutanous.
In contrast when uploading files using streams like sftp/ftp protocol we send only the buffer every time and memory isnt increased a lot and after decreased in contrast to azure.I am really dont know what to do.If I increased the memory size in java options  it could be a lot .
Thanks,
Itay.

Hi @rickle-msft
For listcontainer it increase only in first time.but not decreased.when I uploading 10 files of 50MB the memory increase in 500MB.I can arrive to 1.5 GB memory after uploading 20 files of 50MB.The worst the memory doesn't released even after much time.only some system.gc call after time to time can reduce the memory but not to the original size.my application can send numerous files simutanous.
In contrast when uploading files using streams like sftp/ftp protocol we send only the buffer every time and memory isnt increased a lot and after decreased in contrast to azure.I am really dont know what to do.If I increased the memory size in java options  it could be a lot .
Thanks,
Itay.

@ihudedi This actually doesn't sound like unusual memory behavior to me. I believe in Java, garbage collections are typically triggered when one of the memory tiers becomes full, so waiting extra time won't necessarily decrease memory. Continuing to use the application will eventually trigger a gc cleanup which will remove unreferenced blocks of memory as you noted when you call System.gc().
I don't have much knowledge of the sftp protocol and its implementation. Perhaps they don't do any buffering at all. If you use the stageBlock/commitBlockList/upload methods on BlockBlobClient instead of on BlobClient, those methods are allocation free and should have minimal memory pressure. You'll be in complete control of the memory allocations at that point, so it may be worth giving that a try as well.
@alzimmermsft FYI in case you have any other ideas.

@ihudedi This actually doesn't sound like unusual memory behavior to me. I believe in Java, garbage collections are typically triggered when one of the memory tiers becomes full, so waiting extra time won't necessarily decrease memory. Continuing to use the application will eventually trigger a gc cleanup which will remove unreferenced blocks of memory as you noted when you call System.gc().
I don't have much knowledge of the sftp protocol and its implementation. Perhaps they don't do any buffering at all. If you use the stageBlock/commitBlockList/upload methods on BlockBlobClient instead of on BlobClient, those methods are allocation free and should have minimal memory pressure. You'll be in complete control of the memory allocations at that point, so it may be worth giving that a try as well.
@alzimmermsft FYI in case you have any other ideas.

Hi @rickle-msft
Does upload method has progress?
Upload method what size of block.is it with block size or sending all file,
Thanks,Itay

Hi @rickle-msft
Does upload method has progress?
Upload method what size of block.is it with block size or sending all file,
Thanks,Itay

The upload methods on BlockBlobClient do not currently support progress. We can make a feature request for that if you would like?

The upload methods on BlockBlobClient do not currently support progress. We can make a feature request for that if you would like?

Hi @rickle-msft
When I run
blobClient.getBlockBlobClient().uploadWithResponse(inputStream, fileSize, blobHttpHeaders, null, null, null, null, null, Context.NONE);
I am getting java.util.concurrent.TimeoutException: Channel write operation timed out after 60000 milliseconds.
The file is big and takes more than 60 seconds.
I don't specify timeout in the upload.
Is there any params to disable this check
Thanks,
Itay

Hi @rickle-msft
When I run
blobClient.getBlockBlobClient().uploadWithResponse(inputStream, fileSize, blobHttpHeaders, null, null, null, null, null, Context.NONE);
I am getting java.util.concurrent.TimeoutException: Channel write operation timed out after 60000 milliseconds.
The file is big and takes more than 60 seconds.
I don't specify timeout in the upload.
Is there any params to disable this check
Thanks,
Itay

I responded to this on the other issue that you opened about timeouts specifically

I responded to this on the other issue that you opened about timeouts specifically

Hi @rickle-msft
I tried using upload/getBlobOutputStream/stageBlock+commit
but all meothd increased the memory and it takes much time until GC free the memory.
Do you know which param can I use to force gc frequently to free the memory in jvm param.
Thanks,
Itay

Hi @rickle-msft
I tried using upload/getBlobOutputStream/stageBlock+commit
but all meothd increased the memory and it takes much time until GC free the memory.
Do you know which param can I use to force gc frequently to free the memory in jvm param.
Thanks,
Itay

Hi @rickle-msft
When I uploaded very large file 13GB I am getting this error:
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:?]
at sun.nio.ch.SocketDispatcher.read(Unknown Source) ~[?:?]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) ~[?:?]
at sun.nio.ch.IOUtil.read(Unknown Source) ~[?:?]
at sun.nio.ch.IOUtil.read(Unknown Source) ~[?:?]
at sun.nio.ch.SocketChannelImpl.read(Unknown Source) ~[?:?]
at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253) ~[netty-buffer-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1134) ~[netty-buffer-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at java.lang.Thread.run(Unknown Source) [?:?]

Hi @rickle-msft
When I uploaded very large file 13GB I am getting this error:
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:?]
at sun.nio.ch.SocketDispatcher.read(Unknown Source) ~[?:?]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) ~[?:?]
at sun.nio.ch.IOUtil.read(Unknown Source) ~[?:?]
at sun.nio.ch.IOUtil.read(Unknown Source) ~[?:?]
at sun.nio.ch.SocketChannelImpl.read(Unknown Source) ~[?:?]
at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253) ~[netty-buffer-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1134) ~[netty-buffer-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) [netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at java.lang.Thread.run(Unknown Source) [?:?]

Hi @rickle-msft
Another error when transfering large file:
Caused by: java.lang.RuntimeException: Connection has been closed BEFORE response, while sending request body
at com.azure.storage.common.StorageOutputStream.checkStreamState(StorageOutputStream.java:79) ~[azure-storage-common-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlobOutputStream$BlockBlobOutputStream.writeInternal(BlobOutputStream.java:271) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.azure.storage.common.StorageOutputStream.write(StorageOutputStream.java:118) ~[azure-storage-common-12.10.0.jar!/:?]
at com.bmc.cm.aft.client.AzureFileCopy.copyFile(AzureFileCopy.java:100) ~[classes!/:?]
... 10 more
Suppressed: java.lang.RuntimeException: Connection has been closed BEFORE response, while sending request body
at com.azure.storage.common.StorageOutputStream.checkStreamState(StorageOutputStream.java:79) ~[azure-storage-common-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlobOutputStream.close(BlobOutputStream.java:119) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.bmc.cm.aft.client.AzureFileCopy.copyFile(AzureFileCopy.java:97) ~[classes!/:?]
at com.bmc.cm.aft.client.FileCopy.transfer(FileCopy.java:1560) [classes!/:?]
at com.bmc.cm.aft.client.FileCopy.run(FileCopy.java:1380) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copySingleFile(FTCTransfer.java:876) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copy(FTCTransfer.java:770) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.runCopy(FTCTransfer.java:372) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.run(FTCTransfer.java:301) [classes!/:?]
at com.bmc.cm.aft.client.SubtaskRunner.run(SubtaskRunner.java:610) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runSubTasks(FTCHandler.java:400) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runJob(FTCHandler.java:197) [classes!/:?]
at com.bmc.cm.aft.jobmanagement.JobObjectImpl$JobRunnerThread.run(JobObjectImpl.java:364) [classes!/:?

Hi @rickle-msft
Another error when transfering large file:
Caused by: java.lang.RuntimeException: Connection has been closed BEFORE response, while sending request body
at com.azure.storage.common.StorageOutputStream.checkStreamState(StorageOutputStream.java:79) ~[azure-storage-common-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlobOutputStream$BlockBlobOutputStream.writeInternal(BlobOutputStream.java:271) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.azure.storage.common.StorageOutputStream.write(StorageOutputStream.java:118) ~[azure-storage-common-12.10.0.jar!/:?]
at com.bmc.cm.aft.client.AzureFileCopy.copyFile(AzureFileCopy.java:100) ~[classes!/:?]
... 10 more
Suppressed: java.lang.RuntimeException: Connection has been closed BEFORE response, while sending request body
at com.azure.storage.common.StorageOutputStream.checkStreamState(StorageOutputStream.java:79) ~[azure-storage-common-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlobOutputStream.close(BlobOutputStream.java:119) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.bmc.cm.aft.client.AzureFileCopy.copyFile(AzureFileCopy.java:97) ~[classes!/:?]
at com.bmc.cm.aft.client.FileCopy.transfer(FileCopy.java:1560) [classes!/:?]
at com.bmc.cm.aft.client.FileCopy.run(FileCopy.java:1380) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copySingleFile(FTCTransfer.java:876) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copy(FTCTransfer.java:770) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.runCopy(FTCTransfer.java:372) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.run(FTCTransfer.java:301) [classes!/:?]
at com.bmc.cm.aft.client.SubtaskRunner.run(SubtaskRunner.java:610) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runSubTasks(FTCHandler.java:400) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runJob(FTCHandler.java:197) [classes!/:?]
at com.bmc.cm.aft.jobmanagement.JobObjectImpl$JobRunnerThread.run(JobObjectImpl.java:364) [classes!/:?

@ihudedi here is a decent guide I found after a quick search. It might have some good suggestions. We don't allocate any additional buffers in stageBlock + commit, so if you are seeing memory pressure there, I am skeptical that it is coming from the sdk. I suggest in that case that it may be worth another look at your application to see if it's hold a reference to the memory that the gc can't collect.
What method of upload were you using when you hit these errors?

@ihudedi here is a decent guide I found after a quick search. It might have some good suggestions. We don't allocate any additional buffers in stageBlock + commit, so if you are seeing memory pressure there, I am skeptical that it is coming from the sdk. I suggest in that case that it may be worth another look at your application to see if it's hold a reference to the memory that the gc can't collect.
What method of upload were you using when you hit these errors?

Hi @rickle-msft
I checked the stage/commit and getbloboutputstream.
Both methods results in error when transfer large file.I am using latest version 12.10.
I think in older version 12.9 or 12.10.beta it didnt happen.
Thanks,
Itay

Hi @rickle-msft
I checked the stage/commit and getbloboutputstream.
Both methods results in error when transfer large file.I am using latest version 12.10.
I think in older version 12.9 or 12.10.beta it didnt happen.
Thanks,
Itay

Hi @rickle-msft
It's not working also in older versions.
2021-01-27 11:06:30,343 ERROR [Thread-79] (AzureFileCopy:196) -  Azure copyFile failed : Connection has been closed BEFORE response, while sending request body
reactor.netty.http.client.PrematureCloseException: Connection has been closed BEFORE response, while sending request body

Hi @rickle-msft
It's not working also in older versions.
2021-01-27 11:06:30,343 ERROR [Thread-79] (AzureFileCopy:196) -  Azure copyFile failed : Connection has been closed BEFORE response, while sending request body
reactor.netty.http.client.PrematureCloseException: Connection has been closed BEFORE response, while sending request body

Hi @rickle-msft
Additional error when uploading large file using stage and commit blocks:
2021-01-27 12:08:39,923 ERROR [Thread-291] (AzureFileCopy:196) -  Azure copyFile failed : Status code 400, "?InvalidBlockListThe specified block list is invalid.
RequestId:97f2a22a-b01e-0042-5a94-f4f287000000
Time:2021-01-27T10:08:39.8335430Z"
com.azure.storage.blob.models.BlobStorageException: Status code 400, "?InvalidBlockListThe specified block list is invalid.
RequestId:97f2a22a-b01e-0042-5a94-f4f287000000
Time:2021-01-27T10:08:39.8335430Z"
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) ~[?:?]
at java.lang.reflect.Constructor.newInstance(Unknown Source) ~[?:?]
at com.azure.core.http.rest.RestProxy.instantiateUnexpectedException(RestProxy.java:337) ~[azure-core-1.12.0.jar!/:?]
at com.azure.core.http.rest.RestProxy.lambda$ensureExpectedStatus$5(RestProxy.java:378) ~[azure-core-1.12.0.jar!/:?]
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:118) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1782) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.signalCached(MonoCacheTime.java:320) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.onNext(MonoCacheTime.java:337) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2344) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.onSubscribe(MonoCacheTime.java:276) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:191) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime.subscribeOrReturn(MonoCacheTime.java:132) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:150) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxHandle$HandleSubscriber.onNext(FluxHandle.java:112) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxMap$MapConditionalSubscriber.onNext(FluxMap.java:213) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxHandleFuseable$HandleFuseableSubscriber.onNext(FluxHandleFuseable.java:178) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxContextStart$ContextStartSubscriber.onNext(FluxContextStart.java:96) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1782) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCollectList$MonoCollectListSubscriber.onComplete(MonoCollectList.java:121) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxPeek$PeekSubscriber.onComplete(FluxPeek.java:252) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:136) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.netty.channel.FluxReceive.onInboundComplete(FluxReceive.java:383) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.channel.ChannelOperations.onInboundComplete(ChannelOperations.java:373) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.channel.ChannelOperations.terminate(ChannelOperations.java:429) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.http.client.HttpClientOperations.onInboundNext(HttpClientOperations.java:655) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:96) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1533) ~[netty-handler-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294) ~[netty-handler-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331) ~[netty-handler-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at java.lang.Thread.run(Unknown Source) ~[?:?]
Suppressed: java.lang.Exception: #block terminated with an error
at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:99) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Mono.block(Mono.java:1685) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at com.azure.storage.common.implementation.StorageImplUtils.blockWithOptionalTimeout(StorageImplUtils.java:131) ~[azure-storage-common-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlockBlobClient.commitBlockListWithResponse(BlockBlobClient.java:678) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlockBlobClient.commitBlockListWithResponse(BlockBlobClient.java:648) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlockBlobClient.commitBlockList(BlockBlobClient.java:616) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.bmc.cm.aft.client.AzureFileCopy.copyFile(AzureFileCopy.java:168) [classes!/:?]
at com.bmc.cm.aft.client.FileCopy.transfer(FileCopy.java:1560) [classes!/:?]
at com.bmc.cm.aft.client.FileCopy.run(FileCopy.java:1380) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copySingleFile(FTCTransfer.java:876) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copy(FTCTransfer.java:770) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.runCopy(FTCTransfer.java:372) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.run(FTCTransfer.java:301) [classes!/:?]
at com.bmc.cm.aft.client.SubtaskRunner.run(SubtaskRunner.java:610) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runSubTasks(FTCHandler.java:400) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runJob(FTCHandler.java:197) [classes!/:?]
at com.bmc.cm.aft.jobmanagement.JobObjectImpl$JobRunnerThread.run(JobObjectImpl.java:364) [classes!/:?]

Hi @rickle-msft
Additional error when uploading large file using stage and commit blocks:
2021-01-27 12:08:39,923 ERROR [Thread-291] (AzureFileCopy:196) -  Azure copyFile failed : Status code 400, "?InvalidBlockListThe specified block list is invalid.
RequestId:97f2a22a-b01e-0042-5a94-f4f287000000
Time:2021-01-27T10:08:39.8335430Z"
com.azure.storage.blob.models.BlobStorageException: Status code 400, "?InvalidBlockListThe specified block list is invalid.
RequestId:97f2a22a-b01e-0042-5a94-f4f287000000
Time:2021-01-27T10:08:39.8335430Z"
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) ~[?:?]
at java.lang.reflect.Constructor.newInstance(Unknown Source) ~[?:?]
at com.azure.core.http.rest.RestProxy.instantiateUnexpectedException(RestProxy.java:337) ~[azure-core-1.12.0.jar!/:?]
at com.azure.core.http.rest.RestProxy.lambda$ensureExpectedStatus$5(RestProxy.java:378) ~[azure-core-1.12.0.jar!/:?]
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:118) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1782) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.signalCached(MonoCacheTime.java:320) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.onNext(MonoCacheTime.java:337) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2344) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.onSubscribe(MonoCacheTime.java:276) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxFlatMap.trySubscribeScalarMap(FluxFlatMap.java:191) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoFlatMap.subscribeOrReturn(MonoFlatMap.java:53) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCacheTime.subscribeOrReturn(MonoCacheTime.java:132) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:150) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxHandle$HandleSubscriber.onNext(FluxHandle.java:112) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxMap$MapConditionalSubscriber.onNext(FluxMap.java:213) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxHandleFuseable$HandleFuseableSubscriber.onNext(FluxHandleFuseable.java:178) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxContextStart$ContextStartSubscriber.onNext(FluxContextStart.java:96) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1782) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.MonoCollectList$MonoCollectListSubscriber.onComplete(MonoCollectList.java:121) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxPeek$PeekSubscriber.onComplete(FluxPeek.java:252) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:136) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.netty.channel.FluxReceive.onInboundComplete(FluxReceive.java:383) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.channel.ChannelOperations.onInboundComplete(ChannelOperations.java:373) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.channel.ChannelOperations.terminate(ChannelOperations.java:429) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.http.client.HttpClientOperations.onInboundNext(HttpClientOperations.java:655) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at reactor.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:96) ~[reactor-netty-0.9.15.RELEASE.jar!/:0.9.15.RELEASE]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1533) ~[netty-handler-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294) ~[netty-handler-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331) ~[netty-handler-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) ~[netty-codec-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) ~[netty-transport-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.54.Final.jar!/:4.1.54.Final]
at java.lang.Thread.run(Unknown Source) ~[?:?]
Suppressed: java.lang.Exception: #block terminated with an error
at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:99) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at reactor.core.publisher.Mono.block(Mono.java:1685) ~[reactor-core-3.3.12.RELEASE.jar!/:3.3.12.RELEASE]
at com.azure.storage.common.implementation.StorageImplUtils.blockWithOptionalTimeout(StorageImplUtils.java:131) ~[azure-storage-common-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlockBlobClient.commitBlockListWithResponse(BlockBlobClient.java:678) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlockBlobClient.commitBlockListWithResponse(BlockBlobClient.java:648) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.azure.storage.blob.specialized.BlockBlobClient.commitBlockList(BlockBlobClient.java:616) ~[azure-storage-blob-12.10.0.jar!/:?]
at com.bmc.cm.aft.client.AzureFileCopy.copyFile(AzureFileCopy.java:168) [classes!/:?]
at com.bmc.cm.aft.client.FileCopy.transfer(FileCopy.java:1560) [classes!/:?]
at com.bmc.cm.aft.client.FileCopy.run(FileCopy.java:1380) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copySingleFile(FTCTransfer.java:876) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.copy(FTCTransfer.java:770) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.runCopy(FTCTransfer.java:372) [classes!/:?]
at com.bmc.cm.aft.client.FTCTransfer.run(FTCTransfer.java:301) [classes!/:?]
at com.bmc.cm.aft.client.SubtaskRunner.run(SubtaskRunner.java:610) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runSubTasks(FTCHandler.java:400) [classes!/:?]
at com.bmc.cm.aft.client.FTCHandler.runJob(FTCHandler.java:197) [classes!/:?]
at com.bmc.cm.aft.jobmanagement.JobObjectImpl$JobRunnerThread.run(JobObjectImpl.java:364) [classes!/:?]

Thank you for trying it on older versions. That is helpful information.
The 400 invalid block list error when using stage/commit is a user error that says either one of the blocks you listed isn't actually present or all the block ids are not the same length and base64. You should be able to check the exception for a longer message with an explanation for that.

Thank you for trying it on older versions. That is helpful information.
The 400 invalid block list error when using stage/commit is a user error that says either one of the blocks you listed isn't actually present or all the block ids are not the same length and base64. You should be able to check the exception for a longer message with an explanation for that.

Hi @rickle-msft
I am using uuid.randomuuid to get 36 length and encode in base64
If i upload 2gb its fine.5gb failed on this error or other errors above.
How can i know which blockid i didnt stage? Or commit?
Thanks,
Itay

Hi @rickle-msft
I am using uuid.randomuuid to get 36 length and encode in base64
If i upload 2gb its fine.5gb failed on this error or other errors above.
How can i know which blockid i didnt stage? Or commit?
Thanks,
Itay

The exception message should have some information. You can also call a getBlockList on the target and get all the uncommitted and committed blocks and compare it to the list you tried to commit to see if something is missing.

The exception message should have some information. You can also call a getBlockList on the target and get all the uncommitted and committed blocks and compare it to the list you tried to commit to see if something is missing.

Hi @rickle-msft
When I stage blocks but not commit them what happend to those block that not commited? deleted after a while?
I test when commit blocks that not stage get the invalid block list.
I didn't find a api to get all block list in java via blobClient. can you help me to find it?
Thanks,
Itay

Hi @rickle-msft
When I stage blocks but not commit them what happend to those block that not commited? deleted after a while?
I test when commit blocks that not stage get the invalid block list.
I didn't find a api to get all block list in java via blobClient. can you help me to find it?
Thanks,
Itay

@ihudedi Sorry for the delay. The ones that are staged but not committed will be deleted on any commit. For example, if you stage blocks a, b, and c and you commit list [a, c], then block b will be deleted on the commit. Uncommitted blocks will also be deleted if you do an upload or call delete on the blob. If you stage some blocks and don't do anything, they will be garbage collected after seven days
Surely! BlockBlobClient.listBlocks is what you are looking for.
I'm not quite sure what is going on with the premature close exception. Can you try capturing the x-ms-client-request-id off one of these requests that hits the PrematureCloseException? And I'll do some digging on the backend to try and find why it's closing?

@ihudedi Sorry for the delay. The ones that are staged but not committed will be deleted on any commit. For example, if you stage blocks a, b, and c and you commit list [a, c], then block b will be deleted on the commit. Uncommitted blocks will also be deleted if you do an upload or call delete on the blob. If you stage some blocks and don't do anything, they will be garbage collected after seven days
Surely! BlockBlobClient.listBlocks is what you are looking for.
I'm not quite sure what is going on with the premature close exception. Can you try capturing the x-ms-client-request-id off one of these requests that hits the PrematureCloseException? And I'll do some digging on the backend to try and find why it's closing?

Hi @rickle-msft
Please write your email and I will provide the account name.
BTW how can I know x-ms-client-request-id from the logs because I have numerouse of those?
Thanks,
Itay

Hi @rickle-msft
Please write your email and I will provide the account name.
BTW how can I know x-ms-client-request-id from the logs because I have numerouse of those?
Thanks,
Itay

You can send the information to<EMAIL_ADDRESS>I'm not quite sure what you mean by you have numerous of those. There should only be on request id per request, so just pick any one that's failing with this error.

Hi @rickle-msft
I sent you by email the relevant data.
I attach log to dipslay the error message PrematureCloseException[
[ctmmft.log](
)
](url)
Please let me know if you see something
Thanks,
Itay

Hi @rickle-msft
Please check in the attached file I added above the relevant x-ms-client-request-id
Thanks,
Itay

Hi @rickle-msft  @gapra-msft
We are facing similar issue in our development. We are using latest  azure-storage-blob 12.10.0.
When we upload 500MB file at the time memory spikes for 500MB and in similar way for other file sizes as well , And it gets releases after sometime mostly when the block upload response from Azure Service is received.
You can refer in the screen shot attached that how memory is spikes , I have tried uploading 500MB files two time and both of the times and all the times for other file sizes it spikes almost up to file sizes. This can not work with production use cases with limited memory size.

Now, We have tested the same with V10 SDK : azure-storage-blob  10.1.0
There looks drastic change and memory work very well. But we are not allowed to use the same.
You can refer below screen shot that how 500MB file upload memory worked.

We are looking for such improvement in memory pattern, but we are unable to find it with v12 SDK.
Also We have previously used upload method of SDK but as it has the limitation that MD5 is not available for file size grater than  256MB. Hence we have used BlobOutputStream and writing into it and calculating it on our end. (The first image is of v12 SDK of BlobOutputStream)
Below are some scenario comparison between V10 and V12 SDK.
With V12 SDK:

With v10 SDK:
300/500MB file upload and it is working fine with memory usage (Min- 128MB Max- 256MB memory)

Can your team look into such scenarios and provide improvement in V12 SDK releases.
Let me know incase of any query or concerns.
Thank you.
Dhavalkumar Chauhan.

Hi @rickle-msft @gapra-msft
Any update on above comment by @Dhaval8951 ?
With so many testing of Azure blob storage SDK in different ways and based on our comparison between azure-storage-blob 10.1.0 version and latest version azure-storage-blob 12.10.0 something creates issue in latest version.
Could you please check upload/download with sample program using both version and confirm the case?
If you required any other information, please let us know.
@ihudedi  Can you please try your code with version azure-storage-blob 10.1.0 and share the output?
Thank you. We look forward to hearing from you!!!

Hi @harisingh-highq
Thank you for following up. I will look into what may be holding memory in the v12 SDK. We did recently make a fix to limit the amount of memory buffered which I think may help but I need to confirm this will fix the problem you are seeing.

Hi @ihudedi We recently shipped another fix for memory pressure when using BlobOutputStream. Could you try out 12.11.0-beta.3 to see if it helps with your memory issue?

Hi @gapra-msft
I am now using stage/commit blocks instead of using bloboutputstream and still the same issue until i perform gc manual.

If you could share a sample project that reproduces the issue and share some visual vm traces, that would be helpful so we can identify where this memory is being held.

Hi @gapra-msft
Below code for stage/commit block
Thanks,
Itay
BTW what time the new version will be released ? 12.11.0?
                           ExecutorService executor = Executors.newFixedThreadPool(azureMaxUploadConcurrency);
                            List<Callable<Void>> callableTasks = new ArrayList<Callable<Void>>();
                            long numberOfBlocks = (long) Math.ceil((double) this.fileSize / azureBlockUploadSize);
                            BlockBlobClient blockBlobClient = azureWrapper.getBlobClient(destFile).getBlockBlobClient();
                            for (int i = 0; i < numberOfBlocks && !isInteruppted(); i++) {
                                Callable<Void> callableTask = () -> {
                                    int totalBlockBytesRead = 0;
                                    int numberOfBytesReadOnLastRead = -1;
                                    String base64BlockId = null;
                                    byte[] blockContent = new byte[azureBlockUploadSize];
                                    try {
                                        synchronized (lockRead) { //reading the block synchronize
                                            while (totalBlockBytesRead < azureBlockUploadSize
                                                    && ((numberOfBytesReadOnLastRead = inputStream.read(blockContent, totalBlockBytesRead, Math.min(azureBufferDownloadSize, azureBlockUploadSize - totalBlockBytesRead))) != -1)
                                                    && !isInteruppted()) {
                                                totalBlockBytesRead += numberOfBytesReadOnLastRead;
                                            }
                                            if (totalBlockBytesRead == 0) {
                                                return null;
                                            }
                                            base64BlockId = generateBase64BlockId();
                                        }
                                        if (isInteruppted()) {
                                            return null;
                                        }
                                        byte[] blockContentToUpload = null;
                                        //the array length should be the same as totalBlockBytesRead.
                                        if (totalBlockBytesRead < azureBlockUploadSize) {
                                            blockContentToUpload = new byte[totalBlockBytesRead];
                                            System.arraycopy(blockContent, 0, blockContentToUpload, 0, totalBlockBytesRead);
                                        } else {
                                            blockContentToUpload = blockContent;
                                        }
                                        logger.debug(String.format("Start stage block base64BlockId %s is sized %s bytes", base64BlockId, totalBlockBytesRead));
                                        ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(blockContentToUpload);
                                        blockBlobClient.stageBlock(base64BlockId, byteArrayInputStream, totalBlockBytesRead);
                                        logger.debug(String.format("End stage block base64BlockId %s is sized %s bytes", base64BlockId, totalBlockBytesRead));
                                        byteArrayInputStream.close();
                                        byteArrayInputStream = null;
                                        blockContent = blockContentToUpload = null;
                                        synchronized (lockProgress) {
                                            transferedSize += totalBlockBytesRead;
                                            printTransferredProgress();
                                        }
                                    } catch (Exception e) {
                                        isError = true;
                                        logger.error(String.format("An exception was thrown while uploading base64BlockId %s : %s", base64BlockId, e.getMessage()), e);
                                        azureException = e;
                                        throw e;
                                    } finally {
                                        //releaseMemory();
                                    }
                                    return null;
                                };
                                callableTasks.add(callableTask);
                            }
                            if (!isInteruppted()) {
                                //This is blocking method - wait for all tasks being completed
                                executor.invokeAll(callableTasks);
                                executor.shutdown();
                                if (!isError) {
                                    logger.debug(String.format("Start commit all blocks from the staging area"));
                                    BlobHttpHeaders blobHttpHeaders = null;
                                    if (!isBlobExist) {
                                        blobHttpHeaders = new BlobHttpHeaders();
                                        blobHttpHeaders.setContentType(AS2Utils.TIKA.detect(destFile));
                                    }
                                    blockBlobClient.commitBlockListWithResponse(base64BlockIds, blobHttpHeaders, null, accessTier, null, null, Context.NONE);
                                    logger.debug(String.format("End commit all blocks from the staging area"));
                                } else {
                                    if (azureException != null) {
                                        logger.error("Exception was occurred when trying to upload blocks", azureException);
                                        throw azureException;
                                    } else {
                                        logger.error("Exception was occurred when trying to upload blocks");
                                        throw new AzureException("Exception was occurred when trying to upload blocks");
                                    }
                                }
                            }

Thanks @ihudedi, We will attempt to reproduce as soon as possible.
12.11.0 should be released in the next couple weeks

Hi @gapra-msft Gauri Prasad FTE
I am now using stage/commit blocks instead of using bloboutputstream and still the same issue until i perform gc manual.

There's no guarantee that GC will kick in and remove garbage after upload. Especially if there's no pressure after operation complete. Moreover "manual gc" is just a hint to VM that it should clean up (see here), there's no guarantee it will actually run. You're saying that after you hint VM to perform gc then the garbage is cleaned up - that means SDK didn't hold any references after upload completed but rather GC was lazy.
You can try to run upload in the loop and see if you can see saw pattern.

Hi @gapra-msft  @rickle-msft
The latest version 12.11.1 (blob storage) fixed the issue.
Many bugs related to memory consumption and connectivity issues were solved in this version.
Thanks you very much for the efforts to fix the issue.
Really appreciate.
Itay

@ihudedi  Glad to hear that! I will go ahead and close this issue then. Feel free to post follow up issues on this repo in case you hit anything else!


Add I Am Simme to the blog index

Hi Simon! Thanks for this. Is there any way to filter the posts in the RSS feed to just those about iOS development? I had a quick look but couldn't see any obvious categories.

Ah.. no, sorry. not atm. :/ I could look into it and come back with a new PR later

No problem, it still counts even if there isn't categories. I'd rather have too much than too little! Merging. Thank you.


Consider adding a getting started visual hints

Overview
It's quite common for good UIs to provide a step-by-step visual hints for the new users (add an example)

Hi @roll!We will review this issue after the launch of the stable version. Thanks!


View text box for Timer

As a user, I can see a text box that shows the timer for the task.

Added a view text box for Timer


Left/Right drawer content view jumps on initial opening (since iOS 8)

Hey,
first of all thank you for providing this great code as open source. I have an issue that only occurs since iOS 8.
I am using the drawer controller as follows:
MMDrawerController *drawerController = [[MMDrawerController alloc] initWithCenterViewController:[menuViewController.viewControllers objectAtIndex:0] leftDrawerViewController:menuNavigationController];
    drawerController.showsShadow = NO;
    drawerController.openDrawerGestureModeMask = MMOpenDrawerGestureModeAll;
    drawerController.closeDrawerGestureModeMask = MMCloseDrawerGestureModeAll;
    drawerController.maximumLeftDrawerWidth = 268.0;
    [drawerController setDrawerVisualStateBlock:[MMDrawerVisualState parallaxVisualStateBlockWithParallaxFactor:2.0]];
    drawerController.animationVelocity = 1260.0;

"menuNavigationController" is simply a UINavigationController object with a UITableViewController as its root view controller.
Then, in the center view I have another UINavigationController containing a UITableViewController. In this center view, I use the drawer bar button item to toggle the drawer position with this statement:
[self.mm_drawerController toggleDrawerSide:MMDrawerSideLeft animated:YES completion:nil];

When I do this in iOS 8 for the first time after launch the UITableView cells in the left view first start under the navigation bar (so the first cell is not fully visible) and when the toggle animation is completed they drop down to start below the navigation bar without animation. It looks as if the view controller notices after the view did appear that it has a navigation bar and the content view must start below it.
This does not occur in iOS 7 and it does not occur when the drawer is toggled using a gesture instead of a button or when the drawer is toggled with a button after the initial time.
Any help will be much appreciated.

Still suffering from the same issue. Do not have a navigation controller in my left drawer. Have a SearchBar + UITableView which jumps down on iOS 8 whenever i click on the Search bar or dropdown Header of my tableview. Strangely it does not jump down when I select any of the normal cells.
If only I could find out what is getting called when the Search bar or dropdown Header is being clicked, maybe I could do the same when the in the viewWillAppear section of the Left drawer View Controller.

I'm also facing a similar issue. Same as @vijaytholpadi, I have a SearchBar and UITableView but my issue is when I first open the drawer, my table cells flicker and the width of the cell extends (sort of snaps into place) as the drawer is sliding. This also only happens during the first time it the drawer is opened.

just an update, I think this happens because of the parallax effect. is anyone using that and seeing the same table cell shift?

@huangc10 I am using the parallax effect as well. I remove the effect but the shift still occurs.

+1

For my particular case, it seems to happen when the left/right side controller contains a Top Layout Guide, somehow the guid screws up the layout. Moving the side controller view outside of my storyboard into a dedicated nib fixed the problem.
Ps. XCode 7.0.1

I found a solution which works if you want a "transparent" status bar and you have a search bar in your sideController.
At first just add 2 lines of code after drawerController declaration:
drawerController.showsStatusBarBackgroundView = YES;
drawerController.statusBarViewBackgroundColor = /* UIColor of sideController background */;
Works fine for me.

I have the same isue in Xcode 7.2.  Had someone a solution for Swift - iOS 9.2??  :(

I was having the same issue without a navigation controller and the status bar didn't help me out. @andyzaharia said that the top layout guide was messing it up, so what I did was make sure my constraints were not relative to the top margin but to the top itself. That fixed it in my case.


collection wizard search results stay after deleting query terms

the search results can be very messy. I am missing a way to get rid of them, by deleting the query or having an x button or sth.

probably a bug since they stay even with different query

fixed in 2.1.0-rc.1


get third party lib for openjdk test

related: https://github.com/AdoptOpenJDK/TKG/issues/63
Signed-off-by: OscarQQ<EMAIL_ADDRESS>

https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder_TKG/50/  x86-64_linux

openj9jtregtimeouthandler.jar is only needed for openj9/ibm. Could we limit on JDK_IMPL? Thanks


Fix app show infinite loading page after create workspace from oldDot

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/18351
PROPOSAL: https://github.com/Expensify/App/issues/18351#issuecomment-1536381859
Tests

On Web:

Login to NewDot
Login with same account to OldDot
Create a new free policy in OldDot
Verify that you are redirected to the #admin room with new workspace settings RHP open in NewDot
Verify that there is no infinite loading overlay

On mWeb:

Login to OldDot
Create a new free policy in OldDot
Verify that you are in new workspace settings in NewDot

[x] Verify that no errors appear in the JS console

Offline tests

Can not test when offline
QA Steps

Same as Tests

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/9639873/3df7bfd9-97a4-441b-88d7-4868aba1d299

Mobile Web - Chrome

https://github.com/Expensify/App/assets/9639873/e077f576-b717-4034-b69c-244ed8530c27

Mobile Web - Safari

https://github.com/Expensify/App/assets/9639873/e78aa8d0-8d30-4b92-b067-38c99c5ace02

Desktop

N/A because this issue has not fixed https://github.com/Expensify/App/issues/17391

iOS

N/A

Android

N/A

https://github.com/Expensify/App/assets/25520267/91ef8da0-5c46-4964-9c8d-77b3f9ec150c
The chat is correctly navigated to the workspace admin room, but the infinite loading still appears. I'm testing with a sign-out account.
It's working fine if you already sign-in.

Sorry for the delay @hoangzinh and thanks for the investigation for the LOC!
I'll check the proposal in #21408 and see if it's fix our issue here. Otherwise, we can continue with what we have here and log that issue.

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

Friendly bump @techievivek for a review

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/techievivek in version: 1.3.39-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/francoisl in version: 1.3.39-11 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


bluetooth: config: Fix bluetooth config dependencies

Fix bluetooth config dependencies where the definitions depend on other
definitions.
BT_RX_PRIO is not always defined in a controller only build.
BT_CTLR_TX_BUFFER_SIZE does not depend on BT_CTLR, but BT_LL_SW.
Signed-off-by: Joakim Andersson<EMAIL_ADDRESS>

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@be64964). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #10375   +/-   ##
=========================================
  Coverage          ?    52.9%
=========================================
  Files             ?      210
  Lines             ?    25732
  Branches          ?     5672
=========================================
  Hits              ?    13614
  Misses            ?     9802
  Partials          ?     2316

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update be64964...bc845cf. Read the comment docs.


Create samples for the HttpData (proxy) flow

Feature Request
It would be nice, if we could have some samples about the HttpData flow (push/pull, sync/async).
Which Areas Would Be Affected?
samples
Why Is the Feature Desired?
More and more people are asking how to expose an API through the EDC (e.g. https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/discussions/1578, https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/discussions/1441, https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/discussions/1361)
Solution Proposal
Create one or more samples to demonstrate how the HttpData flows are working and what is needed for it.
Type of Issue
new samples
Checklist

[x] assigned appropriate label?
[x] Do NOT select a milestone or an assignee!

+1