ERROR #6301: SAX XML Parser Error: <STORE>

Question

Question

Roberto Cahanap · Nov 22, 2019

We have a SOAP web service that we call to retrieve a stream of a PDF file. The web service is written by another group in our company (not a Cache group). We are running into one issue where it seems that the PDF is too big and when it is sent to us we get this "ERROR #6301: SAX XML Parser Error: <STORE>". The stream is about 8mb. This is the first time that we have encountered this issue.

We have a WRC ticket open about this but doing some research, we found that if we increase the $ZSTORAGE then we no longer get this error when we call the web service for this 8mb file.

This is currently a PRODUCTION issue where a set of users would like to access this PDF. We were thinking as a solution to have something like this:

Set CurrentZStorage=$ZSTORAGE

Set $ZSTORAGE=32000 //this seems to be the size that allows the PDF to be streamed

...call the web service

Set $ZSTORAGE=CurrentZStorage

The current $ZSTORAGE in our Cache boxes is about 16384. Would doing these steps above cause any issues?

Is there a better solution for us to deal with this web service problem?

Thank you in advance for your help.

Discussion (4)1

Log in or sign up to continue

Vic Sun · Nov 22, 2019

Hello Roberto,

I see that my colleague in the WRC has already addressed some of your concerns in the case, but to share some information with the developer community, here are some documentation links that may be useful to understand <STORE> errors:

Low Memory and <STORE> Errors

$zstorage

bbsiz

The first thing I notice is that your $zstorage is set to 16384. This is far below our modern default of 262144 (see bbsiz documentation). Is there a particular reason you would want to modify $zstorage on the fly rather than just have your system-wide setting be higher?

1 0

score 0 · Answer 1 · 2019-11-22T09:22:35-05:00

Hello Vic. I'm more on the development end (SQL / Stored Procedure / Web Services / Zen) and not sure why we have it set to 16,384. I will have to ask the people on my team as to why this was the number that was set. But it could be what we have had previously and we just retained this number through our various upgrades.

score 0 · Answer 2 · 2019-11-22T09:36:59-05:00

16384 was the default a long time ago back in Caché 2011, and upgrades would not automatically change this value.

It is a good idea to review your memory settings periodically to make sure they still make sense for your application and usage. This value having never been tweaked from its default may be a sign that other memory values were never thoughtfully adjusted, so the following article may be of use to you (or your team):

https://community.intersystems.com/post/intersystems-data-platforms-and-performance-part-4-looking-memory

score 0 · Answer 3 · 2019-11-22T09:53:38-05:00

Thank you! I have given this recommendation to my team. It makes sense to go this route instead of changing the $ZSTORAGE on the fly.