Issue when running from Weblogic + Brix + Wicket - Didn't meet stated Content-Length

186 views
Skip to first unread message

Venkatt

unread,
Mar 4, 2010, 1:59:56 PM3/4/10
to brix-cms-discuss
Hello:

We are trying to evaluate using Brix and in the demo when deployed
under Weblogic, we're seeing an issue. But we have been unsuccessful
in isolating the problem to one area, namely if it's Brix or Wicket or
Weblogic.

Issue: When we deploy the demo (latest from SVN from Mar. 4th, 2010),
under Weblogic - and upon the first request everything works fine. But
when we hit refresh (F5) on the index.html page, we see the following
errors in the Weblogic console:

==========
<Mar 4, 2010 11:56:35 AM EST> <Error> <HTTP> <BEA-101104> <Servlet
execution in servlet context
"weblogic.servlet.internal.WebAppServletContext@5470a0 - appName :
'brixdemo', name: 'brixdemo.war', context-path: '/brixdemo', spec-
version: 'null'" failed, java.net.ProtocolException:
Didn't meet stated Content-Length, wrote: '0' bytes instead of stated:
'318' bytes..
java.net.ProtocolException: Didn't meet stated Content-Length, wrote:
'0' bytes instead of stated: '318' bytes.
at
weblogic.servlet.internal.ServletOutputStreamImpl.ensureContentLength(ServletOutputStreamImpl.java:
422)
at
weblogic.servlet.internal.ServletResponseImpl.ensureContentLength(ServletResponseImpl.java:
1416)
at
weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:
1459)
at
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:
1415)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
Truncated. see log file for complete stacktrace
>
==========

The same code deployed against Tomcat works fine. And in researching
the issue, it seems that in Weblogic when the Servlet does not set the
"Content-Length" appropriately, it throws the above error.

Since I'm not all that familiar with the code, I'm not sure if it's an
issue to be addressed in Wicket or in Brix.

The problem only happens when we refresh the page and in sniffing the
HTML headers the following differences were noted between the first
request and any consecutive requests where it fails:
[REQUEST HEADERS]
In IE7:
Pragma: no-cache

In FireFox:
Cache-Control: max-age=0

When I (using webscrab) intercept and remove the above mentioned
headers from my request stream, the page shows up fine.

Some of the results from Google search also pointed out that this may
be as a result of trying to fetch a cached content that's GZIPed.

Has anyone out there deployed Brix in Weblogic or has anyone
encountered a similar issue in Weblogic???

The same code (WAR file) works fine in Tomcat but not in Weblogic.

Also I believe it's unique to Weblogic+Wicket+Brix because of the
nature of Brix serving the resources as opposed to the web container
serving the content.

Any help is greatly appreciated?

Thanks

Venkatt

Venkatt

unread,
Mar 4, 2010, 2:47:12 PM3/4/10
to brix-cms-discuss
One additional observation we made is this (and this may shed some
light on the problem):

Within Brix the "home page" refers to a page named "index.html". Which
has the following dependencies:

index.html
+
|___ css/style1.css
|___ ../images/bg1.jpg
|___ ../images/header.png
|___ ../images/main-menu-bg.png

and others.

When we created a new page in the Brix content repository under the
name "index.do" with no templates attached (the additional
dependencies with the .css and .jpg and .png are no longer there) and
fetched it via this: http://localhost/brixdemo/index.do

The page worked fine and when we did a F5 to refresh, there were NO
ERRORS.

Next we applied template "/includes/template-with-right-menu.html" to
that same page and loaded up the page. And this time each of the
request for resources such as the style1.css and .jpg's and .png's
threw the same error upon refresh.

So based on this behavior, Weblogic must somehow treat a consecutive
request for the same content differently. And some where in where it
treats each mime-type, it must treat the "*.do"s differently compared
to a ".css" or a ".html".

Does anyone have any suggestions on how to deal with this issue???

Venkatt

Venkatt

unread,
Mar 4, 2010, 4:11:53 PM3/4/10
to brix-cms-discuss
Here's more of my findings:

When deployed under Weblogic after a restart when I request this:

Request-1: http://hv-vguhesan/brixdemo/images/header.png > works fine
and I get the image
Request-2: http://hv-vguhesan/brixdemo/images/header.png > (Refresh)
Throws the error defined in my main email and I get zero bytes back.
Request-3: http://hv-vguhesan/BPortal/images/header.png?foo=bar >
notice the additional parameters I'm passing in - works once again
Request-4: http://hv-vguhesan/BPortal/images/header.png?foo=bar >
(refresh) - once again, I get the error on Weblogic and zero bytes
sent back.
Request-5: http://hv-vguhesan/BPortal/images/header.png?foo=bar2 >
once again works.

So it seems that something different happens when deployed in Weblogic
and a request for cached content is requested.

Any help you can offer is greatly appreciated.

Venkatt

Igor Vaynberg

unread,
Mar 5, 2010, 1:24:46 AM3/5/10
to brix-cms...@googlegroups.com

sounds like weblogic still expects content-length header even for a
cached response? sounds like a bug in weblogic. i wish i could
reproduce it but i dont run it here.

cheers

-igor

>
> Any help you can offer is greatly appreciated.
>
> Venkatt
>

> --
> You received this message because you are subscribed to the Google Groups "brix-cms-discuss" group.
> To post to this group, send email to brix-cms...@googlegroups.com.
> To unsubscribe from this group, send email to brix-cms-discu...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/brix-cms-discuss?hl=en.
>
>

Venkatt

unread,
Mar 5, 2010, 5:56:51 PM3/5/10
to brix-cms-discuss
Hello All:

For now (until we can document it and get a patch with Weblogic), we
are doing the following to make it work. I'm sharing this in hopes
that if others are having a similar issue when using Weblogic, they
can make this quick fix as well.

In <brix-core>
\brix.plugin.site.resource.ResourceRequestTarget.respond(RequestCycle
requestCycle)

you can comment the line that sets the setContentLength(...)

//response.setContentLength(node.getContentLength());

When commented seems to fix the issue. Or you can set the content-
length to zero.

Cheers

Venkatt

Reply all
Reply to author
Forward
0 new messages