[JBoss JIRA] (WFCORE-1418) Reloading host-controller via http-api puts the HC into unresponsive state
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1418?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved JBEAP-3637 to WFCORE-1418:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1418 (was: JBEAP-3637)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.10.Final
(was: 7.0.0.ER5)
Affects Testing: (was: Regression)
> Reloading host-controller via http-api puts the HC into unresponsive state
> --------------------------------------------------------------------------
>
> Key: WFCORE-1418
> URL: https://issues.jboss.org/browse/WFCORE-1418
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Blocker
>
> Reloading host-controller via http-api puts the HC into unresponsive state.
> *reproduce*
> \- create an administrative user admin:asdasd@2
> \- start a domain
> \- reload a server via http api
> {noformat}
> curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"reload","name":"", "address":{"host" : "master"},"json.pretty":1}' -u admin:asdasd@2
> {noformat}
> *actual*
> Default server instances are stopped, HC is left in unresponsive state.
> Keeping the domain alive, following message will appear in 5 minutes, domain will become responsive again after that.
> {noformat}
> [Host Controller] 04:47:23,966 ERROR [org.jboss.as.controller.management-operation] (management task-7) WFLYCTL0349: Timeout after [300] seconds waiting for service container stability while finalizing an operation. Process must be restarted. Step that first updated the service container was 'reload' at address '[("host" => "master")]'
> {noformat}
> *expected*
> Domain is reloaded
> *additional info*
> The issue was introduced by fix for JBEAP-2751 - https://github.com/jbossas/wildfly-core-eap/commit/4986773a51fbf43ad911ae...
> thread dump of unresponsive HC
> http://pastebin.test.redhat.com/348732
> I am unable to reproduce locally, but issue can be easily reproduced on slower servers in MWQE lab. SSLMasterSlave*WayTestCase using reload via http-api cousing failures in domain modules of wf-core testsuite (e.g. [eap-7x-as-testsuite-test-core-rhel|https://url.corp.redhat.com/9f1f544] )
> Regression against 7.0.0.ER4. I was able to reproduce with the latest wildfly-core bits as well (1be598e)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6300) Batch extension fails module deployment if JobOperator provider not found
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6300?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-6300:
-------------------------------------
Not a problem. What was the workaround BTW? I'm kind of curious.
> Batch extension fails module deployment if JobOperator provider not found
> -------------------------------------------------------------------------
>
> Key: WFLY-6300
> URL: https://issues.jboss.org/browse/WFLY-6300
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 9.0.2.Final
> Reporter: Arcadiy Ivanov
> Assignee: James Perkins
>
> I'm a maintainer for JBOSGI, trying to bring the plugin up to 9.x and 10.x.
> Unfortunately, WildFly batch extension assumes that ANY module being inspected will have a classloader capable of finding a JobOperator provider, and if it doesn't the module will not be deployed.
> This assumption is, obviously, wrong.
> Generally the error looks like this:
> {noformat}
> 15:55:56,679 INFO [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0010: Deployed "arquillian-service" (runtime-name : "arquillian-service")
> 15:55:57,049 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /Users/arcivanov/Documents/src/jbosgi/jbosgi/wildfly/build/target/wildfly-9.0.2.Final/standalone/data/content/13/040c763e3f044cd7bbf3475a137bb620158bc1/content
> 15:55:57,055 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "simple-bundle" (runtime-name: "simple-bundle")
> 15:55:57,070 INFO [org.jboss.osgi.framework] (MSC service thread 1-7) JBOSGI011001: Bundle installed: simple-bundle:0.0.0
> 15:55:57,112 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit.simple-bundle.batch.job-operator: org.jboss.msc.service.StartException in service jboss.deployment.unit.simple-bundle.batch.job-operator: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: javax.batch.operations.BatchRuntimeException: The ServiceLoader was unable to find an implemenation for JobOperator. Check classpath for META-INF/services/javax.batch.operations.JobOperator file.
> at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:73)
> at org.wildfly.extension.batch.deployment.JobOperatorService.start(JobOperatorService.java:90)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 15:55:57,112 INFO [org.jboss.as.arquillian] (MSC service thread 1-8) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config.simple-bundle,unit=simple-bundle,tests=[org.jboss.test.osgi.build.SimpleBundleLifecycleTestCase]]
> 15:55:57,118 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011002: Bundle started: simple-bundle:0.0.0
> 15:55:57,120 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "simple-bundle")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.simple-bundle.batch.job-operator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.simple-bundle.batch.job-operator: Failed to start service
> {noformat}
> In more detail, the error looks like this:
> The HostBundleClassLoader is asked by BatchRuntime to enumerate JobOperator services via ServiceLoader.load, returning no providers which triggers an exception.
>
> {noformat}
> 2016-02-29 15:55:57,110 TRACE [org.wildfly.extension.batch] (MSC service thread 1-1) Processing deployment 'simple-bundle' for the batch deployment resources.
> 2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Finding class org.jboss.as.arquillian.service.ArquillianConfig from Module "deployment.arquillian-service:main" from Service Module Loader
> 2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Finding local class org.jboss.as.arquillian.service.ArquillianConfig from Module "deployment.arquillian-service:main" from Service Module Loader
> 2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00337: nextState for action getPolicyConfiguration: open
> 2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Loading class org.jboss.as.arquillian.service.ArquillianConfig locally from Module "deployment.arquillian-service:main" from Service Module Loader
> 2016-02-29 15:55:57,111 DEBUG [org.jboss.security] (MSC service thread 1-2) PBOX00307: Constructing JBossPolicyConfiguration with contextID simple-bundle
> 2016-02-29 15:55:57,111 TRACE [org.jboss.as.naming] (MSC service thread 1-5) Bound resource env into naming store org.jboss.as.naming.ServiceBasedNamingStore@63739568 (service name service jboss.naming.context.java.app.simple-bundle.env)
> 2016-02-29 15:55:57,111 TRACE [org.jboss.as.naming] (MSC service thread 1-7) Bound resource env into naming store org.jboss.as.naming.ServiceBasedNamingStore@63739568 (service name service jboss.naming.context.java.module.simple-bundle.simple-bundle.env)
> 2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00337: nextState for action getPolicyConfiguration: open
> 2016-02-29 15:55:57,111 DEBUG [org.jboss.as.security] (MSC service thread 1-2) Cannot create permissions with 'null' metaData for id=simple-bundle
> 2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-8) Attempting to define class org.jboss.as.arquillian.service.ArquillianConfig in Module "deployment.arquillian-service:main" from Service Module Loader
> 2016-02-29 15:55:57,111 TRACE [org.jboss.osgi.framework] (MSC service thread 1-4) LockManager locked: (START) [simple-bundle:0.0.0, simple-bundle:0.0.0]
> 2016-02-29 15:55:57,111 TRACE [org.jboss.modules] (MSC service thread 1-6) Attempting to find all resources META-INF/services/javax.batch.operations.JobOperator in Module "deployment.simple-bundle:main" from Service Module Loader
> 2016-02-29 15:55:57,111 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-4) Starting bundle: simple-bundle:0.0.0
> 2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00314: commit, contextID: simple-bundle
> 2016-02-29 15:55:57,111 TRACE [org.jboss.osgi.framework] (MSC service thread 1-6) Class [META-INF/services/javax.batch.operations.JobOperator] does not match Dynamic-ImportPackage patterns
> 2016-02-29 15:55:57,112 TRACE [org.jboss.modules] (MSC service thread 1-8) Defined class org.jboss.as.arquillian.service.ArquillianConfig in Module "deployment.arquillian-service:main" from Service Module Loader
> 2016-02-29 15:55:57,111 TRACE [org.jboss.security] (MSC service thread 1-2) PBOX00337: nextState for action commit: inService
> 2016-02-29 15:55:57,112 TRACE [org.jboss.osgi.framework] (MSC service thread 1-4) changeState: simple-bundle:0.0.0 -> STARTING
> 2016-02-29 15:55:57,113 TRACE [org.jboss.osgi.deployment] (MSC service thread 1-4) Invoke: [org.jboss.as.osgi.web.WebContextLifecycleInterceptor,order=1000] with state STARTING on simple-bundle
> 2016-02-29 15:55:57,112 INFO [org.jboss.as.arquillian] (MSC service thread 1-8) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config.simple-bundle,unit=simple-bundle,tests=[org.jboss.test.osgi.build.SimpleBundleLifecycleTestCase]]
> 2016-02-29 15:55:57,112 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit.simple-bundle.batch.job-operator: org.jboss.msc.service.StartException in service jboss.deployment.unit.simple-bundle.batch.job-operator: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: javax.batch.operations.BatchRuntimeException: The ServiceLoader was unable to find an implemenation for JobOperator. Check classpath for META-INF/services/javax.batch.operations.JobOperator file.
> at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:73)
> at org.wildfly.extension.batch.deployment.JobOperatorService.start(JobOperatorService.java:90)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {noformat}
> The questions, therefore, are:
> # Any way for module to indicate it doesn't want to be inspected by WildFly Batch Extension?
> # Should this behavior be fixed in principle?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Harold Campbell (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Harold Campbell commented on WFLY-6283:
---------------------------------------
I'm using standalone-ha-full.xml as a matter of fact.
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> 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.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ELY-431) Improve Elytron HTTP API/SPIs to support more complex authentication mechanisms
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-431?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor updated ELY-431:
---------------------------
Description: This is task is being driven by the requirements around Keycloak and Elytron integration, which will provide as a result a baseline to implement a Keycloak OIDC adapter based on Elytron HTTP API and SPI. (was: Implement a Keycloak OIDC adapter based on Elytron HTTP APIs.)
> Improve Elytron HTTP API/SPIs to support more complex authentication mechanisms
> -------------------------------------------------------------------------------
>
> Key: ELY-431
> URL: https://issues.jboss.org/browse/ELY-431
> Project: WildFly Elytron
> Issue Type: Task
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> This is task is being driven by the requirements around Keycloak and Elytron integration, which will provide as a result a baseline to implement a Keycloak OIDC adapter based on Elytron HTTP API and SPI.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months