Mailing List Archive

Truncated content
I have a user who works with our CSS files. They are managed as stories with one text area element with no maximum length set. Some have grown rather long. She often copies from her text editor and pastes into the Bricolage UI. She has noted that the entire contents have pasted successfully. However, upon saving, the content gets truncated.

This has previously occurred in Chrome, and now is periodically happening in Firefox. I have just replicated in Chrome, though not in Firefox.

I'm not sure if this a Bricolage quirk, but I thought I'd ask the group. Any ideas?

Chris
Re: Truncated content [ In reply to ]
On Apr 10, 2012, at 12:06 PM, Schults, Chris wrote:

> This has previously occurred in Chrome, and now is periodically happening in Firefox. I have just replicated in Chrome, though not in Firefox.
>
> I'm not sure if this a Bricolage quirk, but I thought I'd ask the group. Any ideas?

Make sure it's the browser truncating, rather than something in the data-handling code.

David
RE: Truncated content [ In reply to ]
> Make sure it's the browser truncating, rather than something in the
> data-handling code.

I'm not sure what is going on. First off, I'm occasionally seeing "Apache::SizeLimit httpd process too big" errors, but not every time the content gets truncated. I'm also seeing "(32)Broken pipe: client stopped connection before rflush completed", though I'm not sure if they are related.

What is really weird is that the original file started with:

/* begin CSS reset */

When I add two spaces, the problem goes away:

/* begin CSS reset */

Not only is this happening in Chrome, but also IE. My Firefox seems immune thus far.

I'm left scratching my head.

FYI, the content is 2049 lines long with 50,353 characters.

Here are my Bricolage settings:

CHECK_PROCESS_SIZE = Yes
MAX_PROCESS_SIZE = 325000
CHECK_FREQUENCY = 1
MIN_SHARE_SIZE = 0
MAX_UNSHARED_SIZE = 0

The Apache::SizeLimit errors are reporting sizes from 325000 - 327000.
Re: Truncated content [ In reply to ]
On Apr 10, 2012, at 2:33 PM, Schults, Chris wrote:

>> Make sure it's the browser truncating, rather than something in the
>> data-handling code.
>
> I'm not sure what is going on. First off, I'm occasionally seeing "Apache::SizeLimit httpd process too big" errors, but not every time the content gets truncated.

That should not be related. Those calls should only fire after a request is completed and everything has already been processed and written.

> I'm also seeing "(32)Broken pipe: client stopped connection before rflush completed", though I'm not sure if they are related.

That may well be related. I have seen that detestable error truncate things before. It's a bitch to track down; in the past I have blamed browsers.

> What is really weird is that the original file started with:
>
> /* begin CSS reset */
>
> When I add two spaces, the problem goes away:
>
> /* begin CSS reset */
>
> Not only is this happening in Chrome, but also IE. My Firefox seems immune thus far.
>
> I'm left scratching my head.
>
> FYI, the content is 2049 lines long with 50,353 characters.

You can replicate it every time? Bizarre. I don't recall ever seeing that error message consistently.

> Here are my Bricolage settings:
>
> CHECK_PROCESS_SIZE = Yes
> MAX_PROCESS_SIZE = 325000
> CHECK_FREQUENCY = 1
> MIN_SHARE_SIZE = 0
> MAX_UNSHARED_SIZE = 0
>
> The Apache::SizeLimit errors are reporting sizes from 325000 - 327000.

Seems fine. Those aren't errors, more status messages. You can ignore them.

Best,

David
Re: Truncated content [ In reply to ]
Hi,

> I'm not sure what is going on. First off, I'm occasionally seeing
> "Apache::SizeLimit httpd process too big" errors, but not every time the
> content gets truncated. I'm also seeing "(32)Broken pipe: client stopped
> connection before rflush completed", though I'm not sure if they are
> related.

Do you have a hard memory limit in place? That sounds possible. i.e.
sizelimit is recycling procs ocassionaly, but if you go to far over, you
hit system limit and o/s kills the process and would see the broken pipe
message.

Could check dmesg if you have grsec logging limits, otherwise, strace a
proc and see if you can reproduce it.

Cheers,

Alex
Re: Truncated content [ In reply to ]
On Apr 10, 2012, at 4:26 PM, Alex Krohn wrote:

> Do you have a hard memory limit in place? That sounds possible. i.e.
> sizelimit is recycling procs ocassionaly, but if you go to far over, you
> hit system limit and o/s kills the process and would see the broken pipe
> message.
>
> Could check dmesg if you have grsec logging limits, otherwise, strace a
> proc and see if you can reproduce it.

I love having a genuine in-the-guts sysadmin on this list. Thanks Alex!

David