[JBoss JIRA] (WFLY-7494) Attribute max-connections has wrong error message
by Jan Stefl (JIRA)
[ https://issues.jboss.org/browse/WFLY-7494?page=com.atlassian.jira.plugin.... ]
Jan Stefl updated WFLY-7494:
----------------------------
Tester: Jan Kašík (was: Bogdan Sikora)
> Attribute max-connections has wrong error message
> -------------------------------------------------
>
> Key: WFLY-7494
> URL: https://issues.jboss.org/browse/WFLY-7494
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 11.0.0.Alpha1
>
>
> Error message max-connections is not saying what went wrong, other listeners will have probably same issue
> {noformat}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-connections, value=-20)
> {noformat}
> causes exception
> {noformat}
> 08:54:13,387 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
> 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)
> Caused by: java.lang.IllegalArgumentException: High water must be greater than 0
> at org.xnio.nio.QueuedNioTcpServer.badHighWater(QueuedNioTcpServer.java:236)
> at org.xnio.nio.QueuedNioTcpServer.<init>(QueuedNioTcpServer.java:189)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:200)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:243)
> at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:167)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> ... 3 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-8389) Settings modcluster/ssl-context conflict issue
by Jan Stefl (JIRA)
[ https://issues.jboss.org/browse/WFLY-8389?page=com.atlassian.jira.plugin.... ]
Jan Stefl updated WFLY-8389:
----------------------------
Tester: Jan Kašík (was: Bogdan Sikora)
> Settings modcluster/ssl-context conflict issue
> ----------------------------------------------
>
> Key: WFLY-8389
> URL: https://issues.jboss.org/browse/WFLY-8389
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 11.0.0.Alpha1
> Reporter: Michal Petrov
> Assignee: Michal Petrov
> Fix For: 11.0.0.Alpha1
>
>
> Setting ssl-context in modcluster subsystem
> {noformat}
> /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=ssl-context,value=clientSSLContext)
> {noformat}
> when ssl is configured
> {noformat}
> /subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration
> {noformat}
> shouldn't end as success
> {noformat}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> as {noformat}reload{noformat}
> triggers exception in server log
> {noformat}
> 2017-03-13 10:13:45,394 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 51) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "modcluster")]): java.lang.IllegalStateException: WFLYMODCLS0020: Only one of 'ssl-context' attribute or 'ssl' resource can be defined!
> at org.wildfly.extension.mod_cluster.ModClusterConfigurationServiceBuilder.configure(ModClusterConfigurationServiceBuilder.java:225)
> at org.wildfly.extension.mod_cluster.ModClusterSubsystemAdd.performBoottime(ModClusterSubsystemAdd.java:80)
> at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performBoottime(AbstractBoottimeAddStepHandler.java:157)
> at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:116)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441)
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:381)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> User shouldn't be allowed to set ssl-context in this scenario or be warned.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-9210) XSiteSimpleTestCase doesn't work with different node0 and node1
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-9210?page=com.atlassian.jira.plugin.... ]
Marek Kopecký updated WFLY-9210:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/10425
> XSiteSimpleTestCase doesn't work with different node0 and node1
> ---------------------------------------------------------------
>
> Key: WFLY-9210
> URL: https://issues.jboss.org/browse/WFLY-9210
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> *Description of problem:*
> XSiteSimpleTestCase is design to use node0, node1, node2 and node3. If all these node addresses are set to the same real address (like 127.0.0.1), test pass. Test pass also if these 4 addresses are different. But test fail, if only two addresses are set.
> * Test fail if node0==node2 && node1==node3 && node0!= node1
> * Test pass if node0==node1 && node2==node3 && node0!=node2. But all other tests in TS needs to have different node0 and node1. And XSiteSimpleTestCase is the only one testcase in EAP TS, that needs 4 addresses. So there is no way to run TS with two different IP addresses with passing XSiteSimpleTestCase.
> This is explained by [~rhusar] [here|https://issues.jboss.org/browse/WFLY-5239?focusedCommentId=13304413&...]
> I suggest to
> * keep current default behaviour
> * add new profile, that allows to run XSiteSimpleTestCase with two different IP addresses.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # cd testsuite/integration/clustering
> # mvn clean install -Dmaven.test.failure.ignore=true -Djboss.dist=$JBOSS_DIST -Dtest=XSiteSimpleTestCase \
> -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2
> *Actual results:*
> StackTrace:
> {noformat}
> Running org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 47.186 sec <<< FAILURE! - in org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
> testPutRelayedToBackups(org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase) Time elapsed: 42.766 sec <<< FAILURE!
> java.lang.AssertionError: expected:<200> but was:<500>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutRelayedToBackups(XSiteSimpleTestCase.java:169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> This jira doesn't fix JBEAP-11086
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ELY-1332) NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-1332?page=com.atlassian.jira.plugin.s... ]
Josef Cacek updated ELY-1332:
-----------------------------
Summary: NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload (was: NSS toos based PKCS11 provider defined in Elytron doesn't survive server reload)
> NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload
> --------------------------------------------------------------------------------
>
> Key: ELY-1332
> URL: https://issues.jboss.org/browse/ELY-1332
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> When a SunPKCS11 provider is defined in Elytron subsystem on the top of NSS keystore (e.g. a FIPS one), then the server reload fails with "ProviderException: Secmod module already configured".
> The server.log contains:
> {noformat}
> 08:12:56,073 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.providers.nss: org.jboss.msc.service.StartException in service org.wildfly.security.providers.nss: java.lang.reflect.InvocationTargetException
> at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:224)
> at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:160)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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:748)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:190)
> ... 7 more
> Caused by: java.security.ProviderException: Secmod module already configured
> at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:276)
> at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:107)
> ... 12 more
> ..
> 08:12:56,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("provider-loader" => "nss")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.nss" => "java.lang.reflect.InvocationTargetException
> Caused by: java.lang.reflect.InvocationTargetException
> Caused by: java.security.ProviderException: Secmod module already configured"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ELY-1332) NSS toos based PKCS11 provider defined in Elytron doesn't survive server reload
by Josef Cacek (JIRA)
Josef Cacek created ELY-1332:
--------------------------------
Summary: NSS toos based PKCS11 provider defined in Elytron doesn't survive server reload
Key: ELY-1332
URL: https://issues.jboss.org/browse/ELY-1332
Project: WildFly Elytron
Issue Type: Bug
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Blocker
When a SunPKCS11 provider is defined in Elytron subsystem on the top of NSS keystore (e.g. a FIPS one), then the server reload fails with "ProviderException: Secmod module already configured".
The server.log contains:
{noformat}
08:12:56,073 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.providers.nss: org.jboss.msc.service.StartException in service org.wildfly.security.providers.nss: java.lang.reflect.InvocationTargetException
at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:224)
at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:160)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
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:748)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:190)
... 7 more
Caused by: java.security.ProviderException: Secmod module already configured
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:276)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:107)
... 12 more
..
08:12:56,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("provider-loader" => "nss")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.nss" => "java.lang.reflect.InvocationTargetException
Caused by: java.lang.reflect.InvocationTargetException
Caused by: java.security.ProviderException: Secmod module already configured"}}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4304.
----------------------------------
Fix Version/s: (was: 11.0.0.CR1)
Resolution: Out of Date
This has been configurable for a while
> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
> Key: WFLY-4304
> URL: https://issues.jboss.org/browse/WFLY-4304
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Darran Lofthouse
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (LOGMGR-157) Provide faster alternative to SimpleDataFormat
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-157?page=com.atlassian.jira.plugin... ]
James Perkins edited comment on LOGMGR-157 at 8/10/17 6:46 PM:
---------------------------------------------------------------
So I finally did some testing today and didn't really notice much of a difference. I used the pattern {{"%d %-5p [%c] (%t) %s%e%n"}}. Maybe I should test with just the date to keep it more simple, but the results below are from each type of formatter.
{code:title=SimpleDateFormat}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 835.709 ± 12.675 ns/op
{code}
{code:title=ISO8601DateFormat}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 790.064 ± 5.355 ns/op
{code}
{code:title=DateTimeFormatter}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 873.482 ± 12.207 ns/op
{code}
The {{ISO8601DateFormat}} does appear to be a little faster, but IMO not significant enough to invest in the time of writing our own date formatter. FWIW the {{ISO8601DateFormat}} also has to use a {{ThreadLocal}} because it uses a {{java.util.Calendar}} internally.
It is possible though that using the new {{DateTimeFormatter}} makes sense as it wouldn't require a {{ThreadLocal}} so it would likely produce less garbage.
was (Author: jamezp):
So I finally did some testing today and didn't really notice much of a difference.
{code:title=SimpleDateFormat}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 835.709 ± 12.675 ns/op
{code}
{code:title=ISO8601DateFormat}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 790.064 ± 5.355 ns/op
{code}
{code:title=DateTimeFormatter}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 873.482 ± 12.207 ns/op
{code}
The {{ISO8601DateFormat}} does appear to be a little faster, but IMO not significant enough to invest in the time of writing our own date formatter. FWIW the {{ISO8601DateFormat}} also has to use a {{ThreadLocal}} because it uses a {{java.util.Calendar}} internally.
It is possible though that using the new {{DateTimeFormatter}} makes sense as it wouldn't require a {{ThreadLocal}} so it would likely produce less garbage.
> Provide faster alternative to SimpleDataFormat
> ----------------------------------------------
>
> Key: LOGMGR-157
> URL: https://issues.jboss.org/browse/LOGMGR-157
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Affects Versions: 2.0.6.Final
> Reporter: Koen Janssens
> Attachments: DateFormatPerformance.java
>
>
> Whenever a data or timestamp is included in the logging pattern, SimpleDataFormat is used for formatting. Even with one instance per thread, it is still a heavy beast.
> Other logging libraries (like the 15 year old log4j) have 'fast tracks' for known formats such as ISO 8601. These implementations are faster and generate less memory garbage.
> During profiling, i discovered that simpledateformat is doing a lot of stuff while printing a date:
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.logmanager.handlers.AsyncHandler$AsyncTask.run(AsyncHandler.java:196)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:224)
> at org.jboss.logmanager.formatters.Formatters$5.renderRaw(Formatters.java:389)
> at java.text.DateFormat.format(DateFormat.java:345)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966)
> at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1125)
> at java.util.Calendar.getDisplayName(Calendar.java:2110)
> at java.text.DateFormatSymbols.getInstance(DateFormatSymbols.java:340)
> at java.text.DateFormatSymbols.getProviderInstance(DateFormatSymbols.java:364)
> at sun.util.locale.provider.DateFormatSymbolsProviderImpl.getInstance(DateFormatSymbolsProviderImpl.java:85)
> at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:145)
> at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:710)
> at sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:127)
> at sun.util.resources.LocaleData.getBundle(LocaleData.java:163)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.util.resources.LocaleData$1.run(LocaleData.java:163)
> at sun.util.resources.LocaleData$1.run(LocaleData.java:167)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:890)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1348)
> at java.util.ResourceBundle.checkList(ResourceBundle.java:1400)
> at java.util.Collections$UnmodifiableCollection.isEmpty(Collections.java:1031)
> at java.util.AbstractCollection.isEmpty(AbstractCollection.java:86)
> I have attached a small comparision between simpledateformat performance and log4j ISO formatting performance. It roughly a factor 10 'faster'
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (LOGMGR-157) Provide faster alternative to SimpleDataFormat
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-157?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-157:
--------------------------------------
So I finally did some testing today and didn't really notice much of a difference.
{code:title=SimpleDateFormat}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 835.709 ± 12.675 ns/op
{code}
{code:title=ISO8601DateFormat}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 790.064 ± 5.355 ns/op
{code}
{code:title=DateTimeFormatter}
Benchmark Mode Cnt Score Error Units
PatternFormatterBenchmark.noCause avgt 200 873.482 ± 12.207 ns/op
{code}
The {{ISO8601DateFormat}} does appear to be a little faster, but IMO not significant enough to invest in the time of writing our own date formatter. FWIW the {{ISO8601DateFormat}} also has to use a {{ThreadLocal}} because it uses a {{java.util.Calendar}} internally.
It is possible though that using the new {{DateTimeFormatter}} makes sense as it wouldn't require a {{ThreadLocal}} so it would likely produce less garbage.
> Provide faster alternative to SimpleDataFormat
> ----------------------------------------------
>
> Key: LOGMGR-157
> URL: https://issues.jboss.org/browse/LOGMGR-157
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Affects Versions: 2.0.6.Final
> Reporter: Koen Janssens
> Attachments: DateFormatPerformance.java
>
>
> Whenever a data or timestamp is included in the logging pattern, SimpleDataFormat is used for formatting. Even with one instance per thread, it is still a heavy beast.
> Other logging libraries (like the 15 year old log4j) have 'fast tracks' for known formats such as ISO 8601. These implementations are faster and generate less memory garbage.
> During profiling, i discovered that simpledateformat is doing a lot of stuff while printing a date:
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.logmanager.handlers.AsyncHandler$AsyncTask.run(AsyncHandler.java:196)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:224)
> at org.jboss.logmanager.formatters.Formatters$5.renderRaw(Formatters.java:389)
> at java.text.DateFormat.format(DateFormat.java:345)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966)
> at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1125)
> at java.util.Calendar.getDisplayName(Calendar.java:2110)
> at java.text.DateFormatSymbols.getInstance(DateFormatSymbols.java:340)
> at java.text.DateFormatSymbols.getProviderInstance(DateFormatSymbols.java:364)
> at sun.util.locale.provider.DateFormatSymbolsProviderImpl.getInstance(DateFormatSymbolsProviderImpl.java:85)
> at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:145)
> at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:710)
> at sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:127)
> at sun.util.resources.LocaleData.getBundle(LocaleData.java:163)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.util.resources.LocaleData$1.run(LocaleData.java:163)
> at sun.util.resources.LocaleData$1.run(LocaleData.java:167)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:890)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1348)
> at java.util.ResourceBundle.checkList(ResourceBundle.java:1400)
> at java.util.Collections$UnmodifiableCollection.isEmpty(Collections.java:1031)
> at java.util.AbstractCollection.isEmpty(AbstractCollection.java:86)
> I have attached a small comparision between simpledateformat performance and log4j ISO formatting performance. It roughly a factor 10 'faster'
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (WFLY-9214) Remove experimental Hibernate Search / JGroups integration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9214?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9214:
----------------------------------------
It has been in the EAP branch since April, 2015, which I believe predates when the 7.x branch was rebased on WildFly master.
It came in via https://github.com/wildfly/wildfly/pull/7375.
> Remove experimental Hibernate Search / JGroups integration
> ----------------------------------------------------------
>
> Key: WFLY-9214
> URL: https://issues.jboss.org/browse/WFLY-9214
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Fix For: 11.0.0.CR1
>
>
> The {{<artifactId>hibernate-search-backend-jgroups</artifactId>}} has never matured from its experimental status, and should not have been included in WildFly.
> We never supported it, it's presence is not documented in EAP docs, and should simply be removed as it was a mistake to include it in the first place.
> I'll keep the reference to it as an optional dependency from the module, so that people can still drop in the module if they want to. I just don't believe this should be shipped by default.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months