Submitted by John Foldager on Fri, 02/09/2007 - 00:00
Forums
IceBreak

I have created a simple search-program that lists as many customers as possible in a webpage. Searching for something that generates a lot of data will break the HTML.

The solution was to specify the 'Buffer output size' to '999999999' but the input buffer size is still '0'. What impact does this have on input and/or output? Will an uploaded file that is 'too large' be corrupted as well because of the '0' in input buffer size?

The corruption is kind of weird as I can understand if a buffer has a limit in size and thus the output is truncated to this output buffer size, but try to see the following screenshot of the last bits of HTML in the browser. Please note that I have manually repeated the last couple of lines below the '-----------------------' and marked the content that is missing before '<tr va'! I can understand that the HTML is cut off after '<tr va' but WHY does it leave out content just before these last characters?

Best regards,

John Foldager
www.izone.dk
www.icebreakforum.org

Niels Liisberg

Sat, 02/10/2007 - 00:00

Permalink

The fllowing is subject to change - but is how IceBreak works in the current versions:

The buffer size is static in size in IceBreak. So the output size, input size or Cookie size can not exeed the limit on these buffers.

The size you enter is allocated as terra spaces for the job so the size has an inpact on the overall performance on the System i.

the default sizes in bytes are:

INBUFLEN: 65535
OUTBUFLEN: 2097120
COOKIELEN: 65535


Regards

Niels

Originally Posted by Niels Liisberg:

"The buffer size is static in size in IceBreak. So the output size, input size or Cookie size can not exeed the limit on these buffers.

The size you enter is allocated as terra spaces for the job so the size has an inpact on the overall performance on the System i."
 

I can understand that someone might need this limit in order to prevent download or upload of content greater than a fixed value, but in most applications you would probably allow - at least the output buffer - to be as large as possible. Approximately 2MB limit is okay for most situations but not if you have any kind of file manipulations.

I have had the impression that you could output as much as what is addressable by the 64 bit Server i. Wouldn't it be possible to implement this in a more dynamic way so that only the size of the output is actually allocated in memory? I mean... if the result of this default is that content is just chopped over then I will certainly change all of our server instances to have output buffer of 999999999 bytes - even though it might impact performance. I would rather have a slower reliable application than a responsive non-reliable application.


"the default sizes in bytes are:

INBUFLEN: 65535
OUTBUFLEN: 2097120
COOKIELEN: 65535"


If the above values are the default if you specify '0' for each field (which was what I had in this scenario) then I would really hope that you will consider changing the following for the 5250 add/edit/etc. interfaces:

Have the above values set as default values and maybe have '0' as 'no limit' or if possible for the fieldtype have:
*DFT
*NOLIMIT

In any case please specify the values to the right of the fields with (default: 65535 etc.) so that we can change them back to defaults if we have tried changing them before.
Best regards,

John Foldager
www.izone.dk
www.icebreakforum.org

Is this the same issue that limites the download size of any object to 2MB.

2MB simply is not big enough - If one selects to download a file in the browser, only the first 2MB is transfered. the rest is ignored. The target file is corrupt.

As IceBreak becomes more and more important in document handling/imaging, then a much larger download size is extremely important.

Any ideas?

Regards
Syd