We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Thread blocked in com.aspose.cells.a.d.zfy.<init>

Aspose.Cells Product Family
#1

Running multiple threads, each with an aspose Workbook open for a spreadsheet which we have in a byte[] and passed ByteArrayInputStream to the Workbook. We have 4 threads and each has been given a distinct input stream to the same underlying byte[]. With the aspose code obfuscated, it is difficult to tell why the aspose threads would block each other. The blocked code is within the Workbook constructor. Here is the stack trace:


“application-akka.actor.default-dispatcher-6” -
Thread t@87<o:p></o:p>

java.lang.Thread.State: BLOCKED

at com.aspose.cells.a.d.zfy.(Unknown Source)

- waiting to lock <33e4432> (a com.aspose.cells.a.e.zb) owned by "application-akka.actor.default-dispatcher-8" t@92

at com.aspose.cells.WorkbookSettings.(Unknown Source)

at com.aspose.cells.Workbook.a(Unknown Source)

at com.aspose.cells.Workbook.(Unknown Source)

...


Can you provide some guidance on what could be causing this concurrency issue?

#2

Hi,


Thanks for providing us some details.

Could you provide us sample console JAVA program (runnable) to reproduce the issue on our end with template file (if any), we will check it soon.

Please note, Aspose.Cells (written in pure Java) can be used in multi-threaded environment safely, but you cannot use the same Workbook in multiple threads. As long as you don’t have shared data source and every time a user accesses the application a new Workbook or Excel file is instantiated, there would be no problem at all. However, if you have a shared data/resource, then you will have to do synchronization by yourself. We recommend you to open/create/manipulate data into different workbooks in different threads accordingly, because, you should not use one workbook/file in multiple threads at the same time least you would not get stable data due to restrictions and complexity (involved) put forth by MS Excel itself for its file format(s).

Thank you.
#3

Let me clarify the scenario. Many threads will utilize the same spreadsheet over time. We have a thread pool with size 4, so up to 4 threads need to process against the spreadsheet at once. We have the spreadsheet file data cached into a byte[]. It is not in a file.


We use the Workbook constructor that accepts any InputStream. We create and pass into each of the Workbook objects, a separate instance of ByteArrayInputStream. However, all of the input streams are backed by the same byte[]. The InputStream can only be used for sequential read access to the memory. I would expect no limitation in concurrent access to the byte[] memory by multiple ByteArrayInputStream on different threads.

I am not sure how aspose is implemented. I would expect that the Workbook extracts the spreadsheet data from the InputStream and then works against some internal memory structure.

Can you explain why there is a concurrency problem in this scenario? Are you suggesting that I would need to copy the byte[] for each instance of ByteArrayInputStream, when constructing a Workbook? I don’t understand why having multiple threads sharing access to memory for read-only sequential access via the InputStreams would cause a problem.
#4
Hi,

Thanks for using Aspose.Cells for Java.

Your issue should not be caused by the backed byte[] or accessing the inputstream. We need to know which version you are using when getting this issue so we can trace the issue further by the stack trace. If you are not using our latest version/fix, please try it first because we have solved some concurrent issues in recent versions.

Latest Version Download Link


#5

We are using aspose-cells 8.7.0. I see you guys jumped from 8.9 to 16.x. Latest version is 17.5. Is there reason to believe that upgrading will resolve this issue. If so, then we will upgrade.

#6

Hi,


Thanks for your posting and using Aspose.Cells.

There are many APIs provided by Aspose. All of them were using different version numbers. So, we decided, all of them should follow the same naming scheme. It will be like

Year.Month

So, at the moment, the latest version of Aspose.Cells, Aspose.Words, Aspose.Pdf or any other Aspose API is

17.5

Here
17 means year 2017
5 means month May

Please give a try to most recent version i.e. 17.5. You can try it in Evaluation Mode because Evaluation Mode does not have any limitation except, it will add one extra worksheet with warning message.

But if you find any problem, then please post your question in Aspose.Purchase forum and request them to provide you a temporary license which will help you test the recent version in License Mode. Thank you and have a good day.

#7
Hi,

Thanks for considering Aspose.Cells.

We have investigated the stack trace of your issue further and found that it is the process of loading fonts that blocked the threads. In recent versions, we have optimized the process of loading fonts. So, you should try our latest fix to see whether your issue has been fixed. If not, please send us the stack trace of the new version so we can make further investigation.

One notable thing: all font data will be loaded only once as a static data but the loading process may need certain time. So, for the first time that cells component is initialized, threads still need to be blocked to wait until the font’s data be loaded completely. After that, no thread should be blocked for this process.

#8

I have downloaded aspose.cells v17.5 and tested. We are still seeing the same problem. We have a pool of 4 threads that need to process separate aspose Workbooks in parallel. It appears that aspose is limited to processing only one Workbook at a time across all threads. What we see is that only one thread can run at a time. The others block in the Workbook constructor, waiting for the active thread to complete all processing. Occasionally there is some slight overlap where two threads are active concurrently, but almost always three threads are blocked while one thread runs. This is the stack trace we always see for the blocked threads:


application-akka.actor.default-dispatcher-6" - Thread t@87
java.lang.Thread.State: BLOCKED
at com.aspose.cells.a.d.zfy.(Unknown Source)
- waiting to lock <3d8d534d> (a com.aspose.cells.a.e.zb) owned by “application-akka.actor.default-dispatcher-7” t@90
at com.aspose.cells.WorkbookSettings.(Unknown Source)
at com.aspose.cells.Workbook.a(Unknown Source)
at com.aspose.cells.Workbook.(Unknown Source)
at com.our.code…

We call the Workbook constructor that takes an InputStream argument. We have our Excel workbooks cached in memory as byte arrays. For each thread we create a new ByteArrayInputStream backed by one of the cached byte arrays and pass that into the aspose Workbook constructor.

Based on this stack trace and the described behavior, do you have some idea what would be causing the threads to block?
#9

We have a related issue that the processing time, even when the thread gets control, is getting incrementally slower over time. If we restart the server, then the processing time resets back to initial levels. This behavior would make me suspect a memory leak that is causing eventual thrashing of memory. However, memory utilization does not appear to be a problem on the server.


Is it possible that the aspose Workbook processing is slowing over time - somehow related to the same issue that is causing the thread blocking? To give you an idea of our processing, we write some number of input cell values into spreadsheet cells, run some calculations, then extract output cell values.
#10

I wanted to provide another bit of information. What I see now is that, when we first start the server, the 4 threads are able to process their separate Workbooks in parallel. It is only after the processing time has started to degrade that we begin to see the threads blocking in the Workbook constructor.


Does the stack trace give you any idea on why the threads are blocking? Is aspose managing some internal memory buffer pool, and blocking threads when unable to allocate memory from the buffer?

Greg
#11
Hi,

Thanks for using Aspose.Cells.

We have looked into your stack trace and found, you are using some older version of Aspose.Cells. Because, there are some classes that should not be called if you are using the most recent version.

Please print Aspose.Cells version using the following code and confirm that you are using v 17.5.

Java
System.out.println("Aspose.Cells for Java v" + CellsHelper.getVersion());

Console Output
Aspose.Cells for Java v17.5.0

Besides, we have logged your issue in our database to keep track of your issue and help you out.

This issue has been logged as

  • CELLSJAVA-42317 - Thread blocked in com.aspose.cells.a.d.zfy.

#12

Somehow we were not using the new v17.5 jar. I added code to log the aspose version and copied the file onto the server again. Now the log confirms we are using the v17.5 jar and testing shows the 4 threads are running concurrently throughout processing with no degradation in processing time. Thanks for your help.

#13
Hi,

Thanks for your feedback and using Aspose.Cells.

It is good to know that your issue seems to be resolved in your initial testing after using the latest version. Let us know if you encounter any other issue, we will be glad to look into it and help you further.