Version :
Apache MyFaces 2.1.14 and RichFaces 4.3.5
Issue:
We are migrating from jsf 1.2 to jsf 2. We are facing very strange issue as :
When any ajax operation is performed , we are getting below error and page is not refreshed (or rerended as usual)
org.apache.myfaces.context.servlet.ServletExternalContextImpl setResponseContentType
SEVERE: Cannot set content type. Response already committed
This question is very similar to jsf 2.0 response already commented (ajax) ,
but it seems that no one has answered this question.
It also comes only at the specific page and same code at other places works fine and this error is very random in nature?
Is this anything to do with apache myfaces ?
Please help if any inputs are available .
The xhtml ajax tags causing these issues are : a4j:commandLink and a4j:ajax
That usually occurs because there is an error on render response phase and part of the response has been already send to the client. The algorithm then try to render the error page but it can't because the response has been already sent so you get the problem.
The solution usually is avoid the early commit, increasing the buffer size of the response. To do that use javax.faces.FACELETS_BUFFER_SIZE web config parameter (by default is 1024 bytes).
Theoretically this param has a negative effect over memory, because the larger the buffer, the more memory is allocated for that, but the JVM is fast enough if there is enough memory.
Related
As shown below, when send the request body, the request header is send as the body content.
[enter image description here][1]
I compared the 3.x and 4.x codes, find two versions on the processing of RetryAndFollowUpInterceptor.intercept() is different.
The 4.x version calls the detachWithViolence methods in the finally to release the resource, but the 3.x version does not release the resource if an exception occurs, this results in unsuccessfully send data in the Buffer being consumed by the next request.
Please help to fix this BUG in version 3.x, thank you!
List 135 of class okhttp3.internal.http.RetryAndFollowUpInterceptor does not execute when an excption is thrown.
Because the difference between the two version is too big, the team will not upgrade for the time being.
Could you fix the BUG on the 3.x version?
I am trying to make a POST request to an endpoint served using jetty server. The request errors out saying 413 Request entity too large. But the content-length is only 70KB which I see is way below the default limit of 200KB.
I have tried serving via ngnix server and add client_max_body_size to desired level but that didn't work. I have set the setMaxFormContentSize of WebContext and that didn't help either. I have followed https://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size and that didn't helped me either.
Does anyone have any solution to offer?
wiki.eclipse.org is OLD and is only for Jetty 7 and Jetty 8 (long ago EOL/End of Life). The giant red box at the top of the page that you linked it even tell you this, and gives you a link to the up to date documentation.
If you see a "413 Request entity too large" from Jetty, then it refers the the Request URI and Request Headers.
Note: some 3rd party libraries outside of Jetty's control can also use HttpServletResponse.sendError(413) which would result in the same response status message as you reported.
Judging by your screenshot, which does not include all of the details, (it's really better to copy/paste the text when making questions on stackoverflow, screenshots often hide details that are critical in getting a direct answer), your Cookie header is massive and is causing the 413 error by pushing the Request Headers over 8k in size.
I'm integrating Glimpse to a legacy production application (Upgraded to MVC3). Most pages have a lot of ajax requests and some of the ajax requests return an empty response based on the business logic.
Glimpse client fails to parse such empty responses (out of may be 20-30 responses). Chrome console clearly shows where it fails.
Uncaught TypeError: Cannot call method 'indexOf' of null Glimpse.axd?n=glimpse_client&hash=0a37c827:3633
display.ajax.processContentType Glimpse.axd?n=glimpse_client&hash=0a37c827:3633
display.ajax.update Glimpse.axd?n=glimpse_client&hash=0a37c827:3657
display.ajax.XMLHttpRequest.open
The reason is that the processContentType function is given a 'null' as contentType (variable named 'type' within the function) and the following statement fails.
return type.substring(0, type.indexOf(';'));
What bothers me is the fact that the whole Glimpse window does not show up (Glimpse icon is not hyper-linked to open up the Glimpse tabs) as a result. Is there anyway (configuration?) to workaround the issue?
Thank you!
The issue was resolved by updating Glimpse to 1.5.0.
---Here's the comment from Glimpse;
avanderhoorn commented 6 hours ago
You must be running an old version of Glimpse.core. This was fixed with PR #401 (reported in
#400) and went live in release https://github.com/Glimpse/Glimpse/releases/1.5.0.
All I did was 'Update-Package Glimpse' in VS package manager console and it's fixed now.
I'm experiencing what I think is odd behavior with the JSF validation between Tomcat and Glassfish. Previously we were using Tomcat, but now have requirements to run a full Java EE App Server.
During testing, I noticed when submitting empty fields to the server, that simply have a length validator and no required attribute, Glassfish is outputting the validation message whereas, Tomcat would simply skip the validation on these elements.
If a value is submitted and fails validation everything works fine, it is simply when no value is entered and the page is submitted.
Environment Specifics
JSF Mojarra 2.1.12
Richfaces 4.1
Target server Glassfis 3.1.2
Moving from Tomcat 7.0.27
Here is a snippet of code that contains the described behavior:
<h:inputText id="phoneAreaCode"
maxlength="3"
size="2"
value="#{bean.phoneArea}"
style="margin-left: 8px;">
<f:validateLength minimum="3"/>
<f:validator validatorId="phoneValidator"/>
<a4j:ajax/>
</h:inputText>
Use Case (Tomcat):
If a value is provided, validation occurs. If value passes validation, page is allowed to submit, if it fails, error message is outputted to page.
If no value is provided, no validation occurs, and page is allowed to submit
Use Case (Glassfish):
Same as above
If no value is provided, validation still occurs, and obviously fails.
I am seeing this behavior for custom validators via <f:validator/> tags as well as the built in ones like <f:validateLength/>.
No code difference, just the server the code is running on. I've searched Google and I'm not really finding anything to help. Am I not understanding something about validation? Do you see anything wrong?
This Stackoverflow question sounds like the same issue, I just don't see the solution to prevent my environment from behaving in this manner or how to disable the validation when the field is not required.
Thank you to anyone for helping me out on this.
I had a very similar issue a few days ago and I assume that the property phoneArea might be an Integer or Long. If so, you may take a look at this topic and additionally at this one.
I'm getting some js errors only for some users, and only every once in a while on a page that uses quite a bit of ASP.NET AJAX.
The page also does some intense SQL querying and some string manipulation to highlight text found in the search results.
Could this be a result of performance? Is it always safe to use ASP.NET AJAX in demanding situations or should I be looking to other AJAX techniques?
(By the way the errors I sometime see are):
Message: Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 12031
Message: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near ' '.
ASP.NET AJAX has been known to not be the most performance intensive approach, but that's what you got i suppose in exchange for how simple it is to implement.
I do know you aren't allowed to do any Response.Writes within an update panel. That will cause your second error.
This particular exception is very
common and can be caused by any one of
the following:
1. Calls to Response.Write():
By calling Response.Write() directly you are bypassing the normal
rendering mechanism of ASP.NET
controls. The bits you write are going
straight out to the client without
further processing (well, mostly...).
This means that UpdatePanel can't
encode the data in its special format.
2. Response filters:
Similar to Response.Write(), response filters can change the
rendering in such a way that the
UpdatePanel won't know.
3. HttpModules:
Again, the same deal as Response.Write() and response filters.
4. Server trace is enabled:
If I were going to implement trace again, I'd do it differently.
Trace is effectively written out using
Response.Write(), and as such messes
up the special format that we use for
UpdatePanel.
5. Calls to Server.Transfer():
Unfortunately, there's no way to detect that Server.Transfer() was
called. This means that UpdatePanel
can't do anything intelligent when
someone calls Server.Transfer(). The
response sent back to the client is
the HTML markup from the page to which
you transferred. Since its HTML and
not the special format, it can't be
parsed, and you get the error.
Complete Post : ASP.NET AJAX and Sys.Webforms.PageRequestManagerServerErrorException
You can grab the code which causes the error by using Visual Studio Debug feature. I don't know much but maybe it can help and also Firebug will help you to see server response and data you submit to the server.
Here is a video where you can see how to use Firebug to debug Ajax.
See how I used Firebug to learn jQuery
But I don't think Asp.NET Ajax should be avoided in heavy loaded pages. That is actually what Ajax stands for right ? I mean it also relieves servers to send small pieces of pages instead of requesting the whole page again.