[JBoss JIRA] (JGRP-2283) Lock race condition
by Bela Ban (JIRA)
Bela Ban created JGRP-2283:
------------------------------
Summary: Lock race condition
Key: JGRP-2283
URL: https://issues.jboss.org/browse/JGRP-2283
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.14
The attached program fails to run repeats of tryLock-unlock sequences.
Program and config are attached
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (WFCORE-4083) org.apache.httpcomponents.core requires org.apache.commons.codec
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4083?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-4083:
------------------------------------
[~sannegrinovero] I presume this is something which needs fixing for CD14/EAP 7.2.0? In which case we need to clone a JBEAP issue from this (I can help if you confirm)
CC [~msvehla] I am not sure who the Hibernate Search QE contact is
> org.apache.httpcomponents.core requires org.apache.commons.codec
> ----------------------------------------------------------------
>
> Key: WFCORE-4083
> URL: https://issues.jboss.org/browse/WFCORE-4083
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Sanne Grinovero
> Fix For: 6.0.1.Final
>
>
> In WildFly 14 we get:
> {code:java}
> Exception in thread "Hibernate Search: Elasticsearch transport thread-2" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.BasicScheme.authenticate(BasicScheme.java:168)
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:218)
> 2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.nio.client.MainClientExec.generateRequest(MainClientExec.java:224)
> {code}
> Seems that the *org.apache.httpcomponents.core* (WildFly core) module is not declaring the dependency on module *org.apache.commons.codec* (WildFly full).
> Should this be added as an optional dependency, or maybe the need for this module warrants moving the *org.apache.commons.codec* module to WildFly core ?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (WFLY-10615) Duplicate layer 'base' in integration/elytron testsuite
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10615?page=com.atlassian.jira.plugin... ]
Jan Kalina edited comment on WFLY-10615 at 9/3/18 7:35 AM:
-----------------------------------------------------------
Will be resolved by tagging and upgrade of WildFly Arquillian to version 2.1.2.Final (WFARQ-51).
was (Author: honza889):
Will be resolved by WFARQ-51 (blocked by WFLY-10631)
> Duplicate layer 'base' in integration/elytron testsuite
> -------------------------------------------------------
>
> Key: WFLY-10615
> URL: https://issues.jboss.org/browse/WFLY-10615
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> Testsuite wildfly/testsuite/integration/elytron has workarounded module path problem:
> {code}
> MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
> at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
> at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
> at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
> at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
> at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
> at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
> ... 8 more
> {code}
> This is currently workarounded using following in pom.xml:
> {code}
> <!-- let's override the module.path parent configuration with dummy value, to avoid the "IllegalStateException: Duplicate layer 'base'" -->
> <module.path>foo</module.path>
> {code}
> But this prevent using `org.jboss.as.test.module.util.TestModule`, as it try to put created module into "foo", which fails - adding tests using custom modules requires removing this workaround.
> The reason is {{target/wildfly/modules}} is twice in {{module.path}} system property (when in InstallationManagerService):
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
> Note: when reading {{module.path}} from the test (regardless RunAsClient is used or not), the value is correct:
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (WFLY-10615) Duplicate layer 'base' in integration/elytron testsuite
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10615?page=com.atlassian.jira.plugin... ]
Jan Kalina edited comment on WFLY-10615 at 9/3/18 7:35 AM:
-----------------------------------------------------------
The same error hidden also in {{testsuite/integration/clustering}} - WFLY-10631
was (Author: honza889):
The same error hidden also in {{testsuite/integration/clustering}}
> Duplicate layer 'base' in integration/elytron testsuite
> -------------------------------------------------------
>
> Key: WFLY-10615
> URL: https://issues.jboss.org/browse/WFLY-10615
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 13.0.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> Testsuite wildfly/testsuite/integration/elytron has workarounded module path problem:
> {code}
> MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: Duplicate layer 'base'
> at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305)
> at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182)
> at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127)
> at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86)
> at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47)
> at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185)
> at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128)
> at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63)
> ... 8 more
> {code}
> This is currently workarounded using following in pom.xml:
> {code}
> <!-- let's override the module.path parent configuration with dummy value, to avoid the "IllegalStateException: Duplicate layer 'base'" -->
> <module.path>foo</module.path>
> {code}
> But this prevent using `org.jboss.as.test.module.util.TestModule`, as it try to put created module into "foo", which fails - adding tests using custom modules requires removing this workaround.
> The reason is {{target/wildfly/modules}} is twice in {{module.path}} system property (when in InstallationManagerService):
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
> Note: when reading {{module.path}} from the test (regardless RunAsClient is used or not), the value is correct:
> {code}
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/wildfly/modules:
> /home/jkalina/work/wildfly/testsuite/integration/elytron/target/modules
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (WFCORE-4083) org.apache.httpcomponents.core requires org.apache.commons.codec
by Sanne Grinovero (JIRA)
Sanne Grinovero created WFCORE-4083:
---------------------------------------
Summary: org.apache.httpcomponents.core requires org.apache.commons.codec
Key: WFCORE-4083
URL: https://issues.jboss.org/browse/WFCORE-4083
Project: WildFly Core
Issue Type: Bug
Reporter: Sanne Grinovero
Fix For: 6.0.1.Final
In WildFly 14 we get:
{code:java}
Exception in thread "Hibernate Search: Elasticsearch transport thread-2" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.BasicScheme.authenticate(BasicScheme.java:168)
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.doAuth(HttpAuthenticator.java:239)
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.auth.HttpAuthenticator.generateAuthResponse(HttpAuthenticator.java:218)
2018-09-03 11:58:13,120 ERROR [stderr] (Hibernate Search: Elasticsearch transport thread-2) at org.apache.http.impl.nio.client.MainClientExec.generateRequest(MainClientExec.java:224)
{code}
Seems that the *org.apache.httpcomponents.core* (WildFly core) module is not declaring the dependency on module *org.apache.commons.codec* (WildFly full).
Should this be added as an optional dependency, or maybe the need for this module warrants moving the *org.apache.commons.codec* module to WildFly core ?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (DROOLS-2352) Executable model test coverage: run the optaplanner turtleTests with the executable model turned on and see if it survives the ordeal
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2352?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-2352:
---------------------------------------
Tests retriggered.
> Executable model test coverage: run the optaplanner turtleTests with the executable model turned on and see if it survives the ordeal
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2352
> URL: https://issues.jboss.org/browse/DROOLS-2352
> Project: Drools
> Issue Type: Task
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Tibor Zimányi
>
> For now, we're looking for a one time test. Later I presume the exe model will be come the default, so these tests would just run?
> To run the optaplanner turtle tests, run all tests in optaplanner-examples with the VM parameter `-DrunTurtleTests=true`. They take 48 hours to run. You can also just run one, for example NurseRosteringSolveAllTurtleTest, but don't forget that VM parameter.
> Mario Fusco says you can do this to turn on the executable model:
> {code}
> kieBuilder.buildAll( ExecutableModelProject.class );
> {code}
> I presume you 'd need to hack that in `ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory()`.
> Note: I have no idea if this even make sense: those turtle tests use a drl file input and don't use the kie-maven-plugin. We're looking for a switch to just turn it on and see if they are all still green. Mario thinks it's possible, if I understand it correctly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (DROOLS-2777) Guided Decision Table is changing date field value based on the timezone
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2777?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2777:
--------------------------------
Sprint: 2018 Week 30-32, 2018 Week 33-35 (was: 2018 Week 30-32, 2018 Week 33-35, 2018 Week 36-38)
> Guided Decision Table is changing date field value based on the timezone
> ------------------------------------------------------------------------
>
> Key: DROOLS-2777
> URL: https://issues.jboss.org/browse/DROOLS-2777
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Reporter: Michael Anstis
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Fix For: 7.11.0.Final
>
>
> If I set a Date Field in Guided Decision Table, then change the timezone, restart the server, log in again, the Date Field has *different* value
> Expected: decision-central should never attempt to change the rules automatically without user's knowledge
> h3. Acceptance test
> - Check opening of old asset, created before this change (/)
> - Run server on linux machine (timezone a)
> -- run host on win machine (timezone b) and create [#Assets] (/)
> -- run host on win machine (timezone c) and check [#Assets] (/)
> h4. Assets
> - guided template
> - guided rule
> - guided table simple column
> - guided table brl column
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months