[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1710.
----------------------------
Resolution: Done
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
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
12 years, 9 months
[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1710 at 10/2/13 8:27 AM:
---------------------------------------------------------
As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).
Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a *second* FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.
The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down()}}.
was (Author: belaban):
As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).
Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a second FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.
The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down(){{.
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
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
12 years, 9 months
[JBoss JIRA] (WFLY-2118) PersistenceException breaks default error page
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2118:
--------------------------------------
I wonder if we should change this behaviour? The intention was to make development easier, as you can see stack traces if you are working on localhost (and there are no proxy headers), but it could be confusing as it overrides the default error page.
> PersistenceException breaks default error page
> ----------------------------------------------
>
> Key: WFLY-2118
> URL: https://issues.jboss.org/browse/WFLY-2118
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization@20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> ... 68 more
> {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
12 years, 9 months
[JBoss JIRA] (WFLY-2200) NoSuchElementException after upgrade from Beta13 to Beta14
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2200:
------------------------------
Fix Version/s: 8.0.0.Beta1
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
> Key: WFLY-2200
> URL: https://issues.jboss.org/browse/WFLY-2200
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Beta1
>
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {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
12 years, 9 months
[JBoss JIRA] (WFLY-2200) NoSuchElementException after upgrade from Beta13 to Beta14
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2200:
------------------------------
Affects Version/s: 8.0.0.Beta1
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
> Key: WFLY-2200
> URL: https://issues.jboss.org/browse/WFLY-2200
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {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
12 years, 9 months
[JBoss JIRA] (WFLY-2201) Server-side XTS handlers not added if @WebService#portName is missing
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-2201?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris moved JBTM-1940 to WFLY-2201:
---------------------------------------------
Project: WildFly (was: JBoss Transaction Manager)
Key: WFLY-2201 (was: JBTM-1940)
Component/s: XTS
(was: XTS)
(was: TXFramework)
Security: (was: Public)
Fix Version/s: 8.0.0.Beta1
(was: 5.0.0.Final)
> Server-side XTS handlers not added if @WebService#portName is missing
> ---------------------------------------------------------------------
>
> Key: WFLY-2201
> URL: https://issues.jboss.org/browse/WFLY-2201
> Project: WildFly
> Issue Type: Bug
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 8.0.0.Beta1
>
>
> To reproduce, remove portName or targetNameSpace attributes from org.jboss.narayana.compensations.functional.distributed.DistributedTest in the TXFramework suite. You will see that the test fails with:
> {code}
> "MustUnderstand headers: [{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CoordinationContext] are not understood"
> {code}
> The problem is that the Endpoint is not recognised, by the XTS subsytem, as having a valid @WebService annotation if these attributes are missing. In reality they are optional and an application should be allowed to leave them off. However, these attribute values are used by the XTS subsytem, so we would need to find a way of using the defaults if they are missing from the annotation.
--
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
12 years, 9 months