[JBoss JIRA] (WFCORE-5113) Formatters defined on handlers via the formatter pattern attribute are not properly removed
by Michal Petrov (Jira)
[ https://issues.redhat.com/browse/WFCORE-5113?page=com.atlassian.jira.plug... ]
Michal Petrov reassigned WFCORE-5113:
-------------------------------------
Assignee: Michal Petrov (was: James Perkins)
> Formatters defined on handlers via the formatter pattern attribute are not properly removed
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-5113
> URL: https://issues.redhat.com/browse/WFCORE-5113
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: Michal Petrov
> Priority: Minor
>
> Most handlers on the logging subsystem have a legacy {{formatter}} attribute which accepts a pattern. When a {{named-formatter}} is not defined this value is used and a {{PatternFormatter}} is created for it's usage. However when the handler is removed the wrong name is checked against the formatter to be removed. This formatter is not used so it doesn't really create any issues, however it should be removed as it's not used.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar edited comment on WFLY-13897 at 9/29/20 6:21 AM:
----------------------------------------------------------------
I can reproduce the problem locally with e.g.
{{./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -P="-ts.clustering.cluster.ha.profile,-ts.clustering.cluster.fullha.profile,-ts.clustering.byteman.profile,-ts.clustering.single.profile"}}
even with driver version {{12.0.0.Dev04}}.
{noformat}
Every 2.0s: jps -l | sort ribera.local: Tue Sep 29 12:20:18 2020
1722
51882 org.infinispan.server.loader.Loader
52289 org.infinispan.server.loader.Loader
52995 org.infinispan.server.loader.Loader
53322 org.infinispan.server.loader.Loader
53966 org.infinispan.server.loader.Loader
54582 org.infinispan.server.loader.Loader
54979 org.infinispan.server.loader.Loader
55290 org.infinispan.server.loader.Loader
55916 org.infinispan.server.loader.Loader
58013 sun.tools.jps.Jps
{noformat}
jstack form the server looks like
{noformat}
[rhusar@ribera wildfly]$ jstack 54582
2020-09-29 12:21:04
Full thread dump OpenJDK 64-Bit Server VM (25.265-b01 mixed mode):
"Attach Listener" #181 daemon prio=9 os_prio=31 tid=0x00007fae92008800 nid=0x17507 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"DestroyJavaVM" #180 prio=5 os_prio=31 tid=0x00007fae8c80c800 nid=0x2903 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"SINGLE_PORT-ServerMaster-2-1" #173 prio=5 os_prio=31 tid=0x00007fae922ab000 nid=0x17603 runnable [0x000070000f418000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x00000007bedc3a70> (a io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x00000007bedc3a88> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000007bedc3a20> (a sun.nio.ch.KQueueSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
"RxCachedWorkerPoolEvictor-1" #15 daemon prio=5 os_prio=31 tid=0x00007fae964ba000 nid=0x5903 waiting on condition [0x0000700005541000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007a163dce0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"RxSchedulerPurge-1" #14 daemon prio=5 os_prio=31 tid=0x00007fae8c7cf000 nid=0x5703 waiting on condition [0x000070000543e000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007a163e350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"Log4j2-TF-6-Scheduled-1" #12 daemon prio=5 os_prio=31 tid=0x00007fae8c220800 nid=0xa803 waiting on condition [0x000070000533b000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007a10bdb08> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fae8c06e800 nid=0x4103 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fae8c053800 nid=0x3f03 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fae8f00e800 nid=0x4203 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fae8c04a800 nid=0x3d03 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fae8f84b800 nid=0x3c03 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fae8f80d000 nid=0x4503 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fae8c82b000 nid=0x3203 in Object.wait() [0x0000700004a1d000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000007a089d328> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
- locked <0x00000007a089d328> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fae8c828000 nid=0x4c03 in Object.wait() [0x000070000491a000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000007a089d368> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x00000007a089d368> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
"VM Thread" os_prio=31 tid=0x00007fae8c821800 nid=0x4e03 runnable
"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fae8c810800 nid=0x1f07 runnable
"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fae8c81c000 nid=0x1e03 runnable
"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fae8c81c800 nid=0x5403 runnable
"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fae8c81d800 nid=0x5203 runnable
"GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fae8c81e000 nid=0x2b03 runnable
"GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fae8c00d000 nid=0x2d03 runnable
"GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fae8c00e000 nid=0x5003 runnable
"GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fae8c00e800 nid=0x3003 runnable
"VM Periodic Task Thread" os_prio=31 tid=0x00007fae8c06f000 nid=0x5603 waiting on condition
JNI global references: 2019
{noformat}
but the logs are overwritten.
was (Author: rhusar):
I can reproduce the problem locally with e.g.
{{./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -P="-ts.clustering.cluster.ha.profile,-ts.clustering.cluster.fullha.profile,-ts.clustering.byteman.profile,-ts.clustering.single.profile"}}
even with driver version {{12.0.0.Dev04}}.
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar edited comment on WFLY-13897 at 9/29/20 5:49 AM:
----------------------------------------------------------------
I can reproduce the problem locally with e.g.
{{./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -P="-ts.clustering.cluster.ha.profile,-ts.clustering.cluster.fullha.profile,-ts.clustering.byteman.profile,-ts.clustering.single.profile"}}
even with driver version {{12.0.0.Dev04}}.
was (Author: rhusar):
I can reproduce the problem locally with e.g.
{{./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -P="-ts.clustering.cluster.ha.profile,-ts.clustering.cluster.fullha.profile,-ts.clustering.byteman.profile,-ts.clustering.single.profile"}}
even with driver version 1{{2.0.0.Dev04}}.
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13897:
---------------------------------------
I can reproduce the problem locally with e.g.
{{./integration-tests.sh clean install -Dts.noSmoke -Dts.clustering -P="-ts.clustering.cluster.ha.profile,-ts.clustering.cluster.fullha.profile,-ts.clustering.byteman.profile,-ts.clustering.single.profile"}}
even with driver version 1{{2.0.0.Dev04}}.
> infinispan-server instances provisioned by testsuite never shutdown
> -------------------------------------------------------------------
>
> Key: WFLY-13897
> URL: https://issues.redhat.com/browse/WFLY-13897
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 21.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Priority: Critical
>
> Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFCORE-2592) wildfly-service.exe and jbosspass wrong with # inside
by Lukas Vydra (Jira)
[ https://issues.redhat.com/browse/WFCORE-2592?page=com.atlassian.jira.plug... ]
Lukas Vydra reassigned WFCORE-2592:
-----------------------------------
Assignee: Lukas Vydra
> wildfly-service.exe and jbosspass wrong with # inside
> -----------------------------------------------------
>
> Key: WFCORE-2592
> URL: https://issues.redhat.com/browse/WFCORE-2592
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Beta5
> Reporter: Seb Dk
> Assignee: Lukas Vydra
> Priority: Major
>
> Hi there,
>
> I am installing wildfy 10.1.0 as service on a win 20012 server.
> It is working but I cannot stop the service.
> I figured out where the problem is coming from.
>
> When I installe Wildly as a service, I run the following command:
> E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass *my#pass*
>
> But I can see whe I am trying to stop the service, the command running is:
> E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=*my" "pass* --command=:shutdown
>
> Any workaround?
>
> Thanks,
>
> S.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty edited comment on WFLY-13828 at 9/29/20 2:36 AM:
---------------------------------------------------------------------
Hello, [~mgrossmann] can you please describe this bug in a more detailed way and also what are the steps you are following to reproduce it?
was (Author: rchakrab):
Hello, [~mgrossmann] can you please describe this issue in a more detailed way and what is the bug you are facing?
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty commented on WFLY-13828:
--------------------------------------------
Hello, [~mgrossmann] can you please describe this issue in a more detailed way and what is the bug you are facing?
> remote+tls is not supported by EJBClient and remote-outbound-connection
> -----------------------------------------------------------------------
>
> Key: WFLY-13828
> URL: https://issues.redhat.com/browse/WFLY-13828
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 20.0.1.Final
> Reporter: Matthias Großmann
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Hi,
> in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL.
> This is possible with the Uri scheme "remote+tls" provided by jboss-remoting
> https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> {code:java}
> final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
> ...
> endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
> {code}
> But that uri scheme is not supported by the jboss-ejb-client in current version
> https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
> {code}
> public boolean supportsProtocol(final String uriScheme) {
> switch (uriScheme) {
> case "remote":
> case "remote+http":
> case "remote+https":
> // compatibility
> case "remoting":
> case "http-remoting":
> case "https-remoting": {
> return true;
> }
> default: {
> return false;
> }
> }
> }
> {code}
> and also the remote-outbound-connection does not allow that protocol:
> https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
> {code}
> public enum Protocol {
> REMOTE("remote"),
> REMOTE_HTTP("remote+http"),
> HTTP_REMOTING("http-remoting"),
> HTTPS_REMOTING("https-remoting"),
> REMOTE_HTTPS("remote+https");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (DROOLS-5680) STANDARD_DRL property reactivity doesn't recognize multiple properties in an expression
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-5680:
------------------------------------
Summary: STANDARD_DRL property reactivity doesn't recognize multiple properties in an expression
Key: DROOLS-5680
URL: https://issues.redhat.com/browse/DROOLS-5680
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.43.1.Final
Reporter: Hiroko Miura
Assignee: Mario Fusco
When a constraint expression has multiple properties, standard drl (MvelConstraint.calculateMaskFromExpression()) enlists only the first property for property reactivity (e.g. 'age' in the below case) while executable model can react on both.
{noformat}
$p : Person( age > salary )
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months