[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4539:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> logging statement to trace remoting heartbeat
> ---------------------------------------------
>
> Key: WFLY-4539
> URL: https://issues.jboss.org/browse/WFLY-4539
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Carsten Lichy-Bittendorf
> Assignee: Peter Palaga
> Priority: Minor
> Fix For: 11.0.0.Final
>
>
> you can set the heartbeat on a remoting connection by setting:
> remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
> What is missing is the option to log on the client when the heartbeat message is fired.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6321:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
> Key: WFLY-6321
> URL: https://issues.jboss.org/browse/WFLY-6321
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 11.0.0.Final
>
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-6104) Too many invocations to a remote EJB from multiple threads cause infinite wait
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6104?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6104:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Too many invocations to a remote EJB from multiple threads cause infinite wait
> ------------------------------------------------------------------------------
>
> Key: WFLY-6104
> URL: https://issues.jboss.org/browse/WFLY-6104
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.0.0.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Fix For: 11.0.0.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1302181
> While a thread (1) of EJB client invokes a remote EJB which needs long
> processing time and wait for the response, if the other threads complete
> more than 65536 invocations to the remote EJB, EJBCLIENT000011 message like
> below occurs in EJB client side and the waiting thread (1) falls into
> infinite wait for the response.
> INFO: EJBCLIENT000011: Discarding result for invocation id 0 since no
> waiting context found
> All invocations should successfully complete regardless of the number of
> invocations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5400) Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5400:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
> ------------------------------------------------------------------------------------
>
> Key: WFLY-5400
> URL: https://issues.jboss.org/browse/WFLY-5400
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, JMS
> Affects Versions: 10.0.0.CR1
> Reporter: Miroslav Novak
> Assignee: ANGELA ROBERTSON
> Fix For: 11.0.0.Final
>
> Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml
>
>
> Failover of standalone JMS client fails if netty (blocking/non-blocking) connector is used. There are 2 EAP 7.0.0.DR10 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed then backup activates but client does not failover to it:
> {code}
> ent message with property count: 110867, messageId:ID:20310150-62a0-11e5-ada8-b3332c72af23
> Sent message with property count: 110868, messageId:ID:20310151-62a0-11e5-ada8-b3332c72af23
> Sep 24, 2015 11:39:27 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:40 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:55 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:40:10 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> {code}
> Attaching live/backup configuration.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-3316) Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3316?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3316:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-3316
> URL: https://issues.jboss.org/browse/WFLY-3316
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
> Labels: ejb, naming, remote-clients, remote-ejb-connection
> Fix For: 11.0.0.Final
>
> Attachments: reproducer.zip
>
>
> If a client run multi threads and each Thread use it's own InitialContext the behaviour is unexpected.
> The behaviour is as followed:
> if each invocation create it's own IC and lookup the EJB there is sometimes a EJBCLIENT000025 because one of the one thread has closed the IC until another thread try to invoke an EJB.
> If the IC is reused the failure might happen only if the first Thread has finished the invocations and close the IC during other Threads are still running.
> It looks that the underlying remote connection will be closed if the first IC is closed without respect that there are different IC's created and still in use.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-7289) Adding ldap-key-store requires accessible ldap server
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7289?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7289:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Adding ldap-key-store requires accessible ldap server
> -----------------------------------------------------
>
> Key: WFLY-7289
> URL: https://issues.jboss.org/browse/WFLY-7289
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> Playing with ldap-key-store . What I consider very unconvenient is fact, that in moment of adding ldap-key-store, ldap server has to be running and accessible. Elytron ldap-realm does not need that. Doubt about legacy security realms. Is it possible to decouple that dependency and leave that check till first ldap-key-store usage?
> Steps to reproduce:
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/dir-context=a:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=elytron/ldap-key-store=a:add(dir-context=a, search-path="a")
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {code}
> leads to exception in server log
> {code}
> 14:37:25,917 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
> "address" => [
> ("subsystem" => "elytron"),
> ("ldap-key-store" => "a")
> ],
> "operation" => "add",
> "search-path" => "a",
> "dir-context" => "a",
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> }]: java.lang.IllegalStateException: ELY02015: Failed to obtain DirContext
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:126)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.engineSize(LdapKeyStoreSpi.java:381)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.security.keystore.DelegatingKeyStoreSpi.engineSize(DelegatingKeyStoreSpi.java:121)
> at java.security.KeyStore.size(KeyStore.java:1271)
> at org.wildfly.extension.elytron.KeyStoreResource.containsAliases(KeyStoreResource.java:163)
> at org.wildfly.extension.elytron.KeyStoreResource.getChildTypes(KeyStoreResource.java:61)
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildTypes(AbstractModelResource.java:372)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:287)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:291)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:276)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:262)
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:250)
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:787)
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:520)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:758)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:709)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.naming.NamingException: Cannot parse url: undefined [Root exception is java.net.MalformedURLException: Invalid URI: undefined]
> at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:92)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:163)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> ... 39 more
> Caused by: java.net.MalformedURLException: Invalid URI: undefined
> at com.sun.jndi.toolkit.url.Uri.parse(Uri.java:199)
> at com.sun.jndi.toolkit.url.Uri.init(Uri.java:138)
> at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:82)
> ... 56 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4894) ORB error message seen on shutdown time to time - "IOP01210228: (BAD_OPERATION) This ORB instance has been destroyed, so no operations can be performed on it"
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4894?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4894:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> ORB error message seen on shutdown time to time - "IOP01210228: (BAD_OPERATION) This ORB instance has been destroyed, so no operations can be performed on it"
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4894
> URL: https://issues.jboss.org/browse/WFLY-4894
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Reporter: Ondra Chaloupka
> Assignee: Tomasz Adamski
> Fix For: 10.0.0.Final
>
>
> As jira WFLY-4548 describes there could be seen IIOP errors during server shutdown. As issue was fixed it seemed that the trouble went away. Unfortunatelly in some more testing I'm hitting the exception once again when running crash server tests with transactions under jts.
> {code}
> WARNING [javax.enterprise.resource.corba._INITIALIZING_.rpc.presentation] (Thread-87) "IOP01210228: (BAD_OPERATION) This ORB instance has been destroyed, so no operations can be performed on it": org.omg.CORBA.BAD_ OPERATION: vmcid: SUN minor code: 228 completed: No
> at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbDestroyed(ORBUtilSystemException.java:586)
> at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbDestroyed(ORBUtilSystemException.java:608)
> at com.sun.corba.se.impl.orb.ORBImpl.checkShutdownState(ORBImpl.java:1329)
> at com.sun.corba.se.impl.orb.ORBImpl.isDuringDispatch(ORBImpl.java:1340)
> at com.sun.corba.se.impl.oa.poa.POAImpl.destroy(POAImpl.java:959)
> at com.arjuna.orbportability.internal.orbspecific.oa.implementations.POABase.destroyRootPOA(POABase.java:68)
> at com.arjuna.orbportability.oa.core.OA.destroyRootPOA(OA.java:97)
> at com.arjuna.orbportability.RootOA.destroy(RootOA.java:91)
> at com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.ORBRunner.run(ORBRunner.java:59)
> {code}
> The scenario is something:
> - starting server under profile standalone-full.xml with in-vm ActiveMQ messaging
> - setting server via CLI
> - setting transaction running under JTS
> - deploy application containing MDB reading message from ActiveMQ
> - crash server
> - start again and doing recovery
> - stop server (now the exception is shown)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5436) Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5436?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5436:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-5436
> URL: https://issues.jboss.org/browse/WFLY-5436
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> EmbeddedCacheManager has defineConfiguration(...) methods for defining a new cache configuration, but has no equivalent "undefine" method. Consequently, once defined, a cache manager will retains a reference to the cache configuration object for the lifetime of the cache manager. While this is normally not a big deal, the configuration objects generated by WildFly contain references to the classloaders of foreign modules.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5309) jsf/richfaces problem on wildfly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5309?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-5309:
-----------------------------
Fix Version/s: 10.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 10.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> jsf/richfaces problem on wildfly
> ---------------------------------
>
> Key: WFLY-5309
> URL: https://issues.jboss.org/browse/WFLY-5309
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 9.0.1.Final
> Reporter: Ja kub
> Assignee: Dmitrii Tikhomirov
> Fix For: 10.0.0.Final
>
> Attachments: pom.xml, wildfly-test-RF-4.5.8.tar.gz, wildfly-test.rar
>
>
> attached application with
> <jsf.version>2.2.2</jsf.version>
> <org.richfaces.version>4.3.7.Final</org.richfaces.version>
> works fine on wildfly 8.0, on above versions there is a stacktracee,
> now I have tested on 9.0.1 with following result:
> 14:29:38,973 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started in 48493ms - Started 888 of 1068 services (221 services are lazy, passive or on-demand)
> 14:29:43,690 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /webshop/acme.xhtml: java.lang.IllegalStateException
> at com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:712)
> at com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:239)
> at org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55)
> at org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64)
> at org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:424)
> at com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:598)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:673)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:164)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118)
> at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:103)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:154)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:199)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:110)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:202)
> at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:180)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:176)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months