[JBoss JIRA] (RF-13317) ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13317?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13317:
---------------------------------
Backport issue opened here: https://issues.jboss.org/browse/RF-13507
> ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()
> -----------------------------------------------------------------------------------------------
>
> Key: RF-13317
> URL: https://issues.jboss.org/browse/RF-13317
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Environment: Wildfly-8.0.0.Beta1, jsf-impl-2.2.3-jbossorg-1
> Reporter: Matti Bickel
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: backport, jsf22
> Fix For: 5.0.0.Alpha3
>
>
> I'm using several {{<rich:autocomplete>}} fields in a {{<h:form>}}, but have noticed the issue with several other AJAX requests:
> When the response comes back, the data is fine but I get a JSF error saying
> bq. During update: javax.faces.ViewState not found
> Following that, no componentData is available to the Autocomplete component and no suggestions get displayed.
> For reference the [javadoc for ResponseStateManager.VIEW_STATE_PARAM|https://javaserverfaces.java.net/no...] says:
> {quote}
> Implementations must use this constant field value as the name of the client parameter in which to save the state between requests. The id attribute must be a concatenation of the return from UIComponent.getContainerClientId(javax.faces.context.FacesContext), the return from UINamingContainer.getSeparatorChar(javax.faces.context.FacesContext), this constant field value, the separator char, and a number that is guaranteed to be unique with respect to all the other instances of this kind of client parameter in the view.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-12897 at 2/13/14 1:16 PM:
----------------------------------------------------------
I will check - un-scheduling for assessment and re-scheduling.
was (Author: lfryc):
I will check - un-assigning for assessment and scheduling.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
by Marcel Šebek (JIRA)
[ https://issues.jboss.org/browse/RF-13250?page=com.atlassian.jira.plugin.s... ]
Marcel Šebek commented on RF-13250:
-----------------------------------
I'll try to answer your questions and describe the environment in which I see the leaking behavior. I also present some ideas what could be the cause.
The first thing is that 'old-version' atmosphere requests seem to be one way how to rapidly create a huge number (in our case 700 000) of AtomicBoolean instances. However, even without such requests, heap gets exhausted. I suspect a relation to RFPL-2345 - problem with dead sessions. With RF 4.3.3, heap gets filled with MessageData classes, even with org.atmosphere.cpr.CometSupport.maxInactiveActivity = 60000 and org.richfaces.push.session.maxInactiveInterval = 60000 parameters. However, with RF 4.3.5, heap gets filled with AtomicBoolean and char[] instances (and possibly other classes). The heap growth in both cases is similar and very non-linear. In the beginning, the number is 0 (for MessageData) or low (AtomicBoolean), but after some time, it starts to grow and the speed of grow increases. The application runs in non-critical production environment, so I cannot tell exactly what the clients are doing, but it seems that new dead session appears from time to time, and with each new dead session, the speed of memory exhaustion grows.
I'm not sure if I'd be able to isolate a small testcase. However, I have a heap dump which I can provide you. I don't want to provide it publicly (it may contant some sensitive information), but if you are interested, I can provide it to you privately. It is about 70M gzipped.
Finally, here are the answers for your questions.
Except a few libraries, I don't use any framework that should affect the result. The application is deployed on jboss 7.1 (latest build from git) with default jsf (mojarra 2.1.16) and native ssl on 64-bit linux. Extreme memory usage was not my invention, this name was chosen by original bug reporter. However, in my case, the application exhausts 0.75 GB heap with quite low but continuous load in scope of days (like 1-3 days). Low load means something like at most 5 clients simultaneously, but often just one client. The application is pushing just "null" messages (requests for re-rendering) with no useful data.
Any additional questions or suggestions what to try are welcome.
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
> Key: RF-13250
> URL: https://issues.jboss.org/browse/RF-13250
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
> Reporter: Milo van der Zee
> Assignee: Pavol Pitonak
> Labels: memoryleak
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12897:
----------------------------
Fix Version/s: (was: 5-Tracking)
I will check - un-assigning for assessment and scheduling.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13317) ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()
by Steve Oh (JIRA)
[ https://issues.jboss.org/browse/RF-13317?page=com.atlassian.jira.plugin.s... ]
Steve Oh commented on RF-13317:
-------------------------------
backporting to 4.3 would be great ;) see my SO question: http://stackoverflow.com/questions/21726718/can-i-use-fixviewstate-js-fro...
regards
> ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()
> -----------------------------------------------------------------------------------------------
>
> Key: RF-13317
> URL: https://issues.jboss.org/browse/RF-13317
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Environment: Wildfly-8.0.0.Beta1, jsf-impl-2.2.3-jbossorg-1
> Reporter: Matti Bickel
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: backport, jsf22
> Fix For: 5.0.0.Alpha3
>
>
> I'm using several {{<rich:autocomplete>}} fields in a {{<h:form>}}, but have noticed the issue with several other AJAX requests:
> When the response comes back, the data is fine but I get a JSF error saying
> bq. During update: javax.faces.ViewState not found
> Following that, no componentData is available to the Autocomplete component and no suggestions get displayed.
> For reference the [javadoc for ResponseStateManager.VIEW_STATE_PARAM|https://javaserverfaces.java.net/no...] says:
> {quote}
> Implementations must use this constant field value as the name of the client parameter in which to save the state between requests. The id attribute must be a concatenation of the return from UIComponent.getContainerClientId(javax.faces.context.FacesContext), the return from UINamingContainer.getSeparatorChar(javax.faces.context.FacesContext), this constant field value, the separator char, and a number that is guaranteed to be unique with respect to all the other instances of this kind of client parameter in the view.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13531) selects: cannot select option on IE11
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-13531?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek commented on RF-13531:
----------------------------------
Verified, leaving opened for verification in RF 4.5 and 5
> selects: cannot select option on IE11
> -------------------------------------
>
> Key: RF-13531
> URL: https://issues.jboss.org/browse/RF-13531
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-selects
> Affects Versions: 4.3.5, 4.5.0.Alpha2, 5.0.0.Alpha3
> Environment: IE 11
> Reporter: Jiří Štefek
> Assignee: Brian Leathem
> Labels: IE11
> Fix For: 4.3.6
>
>
> Components: autocomplete, select, inplaceSelect.
> Works on IE 10.
> ----
> Issues:
> * User cannot visually select an option from the popup list == moving mouse over the items in the list will not change theirs class.
> ** however clicking on the item will select the option correctly. {color:red}EXCEPT autocomplete (RF4), where it will not select anything{color}.
> ** workaround: the item can be selected, when moving off the list and back to it on the correct item, but the cursor should not move through scroller.
> * User cannot select option with keyboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (RF-13531) selects: cannot select option on IE11
by Jiří Štefek (JIRA)
[ https://issues.jboss.org/browse/RF-13531?page=com.atlassian.jira.plugin.s... ]
Jiří Štefek updated RF-13531:
-----------------------------
Labels: IE11 (was: IE11 needs-qe)
> selects: cannot select option on IE11
> -------------------------------------
>
> Key: RF-13531
> URL: https://issues.jboss.org/browse/RF-13531
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-selects
> Affects Versions: 4.3.5, 4.5.0.Alpha2, 5.0.0.Alpha3
> Environment: IE 11
> Reporter: Jiří Štefek
> Assignee: Brian Leathem
> Labels: IE11
> Fix For: 4.3.6
>
>
> Components: autocomplete, select, inplaceSelect.
> Works on IE 10.
> ----
> Issues:
> * User cannot visually select an option from the popup list == moving mouse over the items in the list will not change theirs class.
> ** however clicking on the item will select the option correctly. {color:red}EXCEPT autocomplete (RF4), where it will not select anything{color}.
> ** workaround: the item can be selected, when moving off the list and back to it on the correct item, but the cursor should not move through scroller.
> * User cannot select option with keyboard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months