[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann edited comment on WFLY-13828 at 9/29/20 7:19 AM:
-------------------------------------------------------------------
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7 over SSL.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol="remote+tls")
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
was (Author: mgrossmann):
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7 over SSL.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
> 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)
5 years
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann edited comment on WFLY-13828 at 9/29/20 7:18 AM:
-------------------------------------------------------------------
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7 over SSL.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
was (Author: mgrossmann):
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
> 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)
5 years
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ]
Matthias Großmann commented on WFLY-13828:
------------------------------------------
Hi [~rchakrab]
basically i would like to add a remote-outbound-connection from a Wildfly 20 to a JBoss AS 7.
For this purpose JBoss Remoting offers the protocol "remote+tls".
But neither JBoss EJB Client nor the Remoting Subsystem are supporting that protocol as described above.
{code}
/subsystem=remoting/remote-outbound-connection=remote-connection-node1:add(outbound-socket-binding-ref=node1, security-realm=ejb-security-realm-ssl, username=xxxxx, protocol=
http-remoting https-remoting remote remote+http remote+https
{code}
{code}
WFLYCTL0248: Invalid value remote+tls for protocol; legal values are [remote+https, http-remoting, remote, https-remoting, remote+http]",
{code}
In my opinion the fix would be to add the additional String "remote+tls" to the two classes above
- https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
- https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
What is the preferred way to do this? Should i provide a pull request or do you want to have a look at it for yourself?
Thank you and kind regards
Matthias
> 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)
5 years
[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)
5 years
[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)
5 years
[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)
5 years
[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)
5 years