[JBoss JIRA] (WFLY-10742) Wildfly 13 having wrong version of Maven dependency
by Peter K (JIRA)
[ https://issues.jboss.org/browse/WFLY-10742?page=com.atlassian.jira.plugin... ]
Peter K updated WFLY-10742:
---------------------------
Description:
I have following Maven dependency in my pom.xml:
{code:xml}
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>20.0</version>
</dependency>
{code}
A) When running it on wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171, it is complaining about a missing method in the Guava library (which is a Guava version < 20.0):
{noformat}
2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) Exception in thread "Thread-182" java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator;
2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) at org.reflections.Reflections.expandSuperTypes(Reflections.java:380)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.reflections.Reflections.<init>(Reflections.java:126)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.api.ops.factory.DefaultOpFactory.<init>(DefaultOpFactory.java:71)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.Class.newInstance(Class.java:442)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initWithBackend(Nd4j.java:6192)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initContext(Nd4j.java:6087)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.<clinit>(Nd4j.java:201)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at java.lang.Thread.run(Thread.java:748)}}
{noformat}
B) It runs on Mac OS X 10.13.5 with Java 1.8.0_144 without errors.
was:
I have following Maven dependency in my pom.xml:
{{<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>20.0</version>
</dependency>}}
A) When running it on wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171, it is complaining about a missing method in the Guava library (which is a Guava version < 20.0):
{{2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) Exception in thread "Thread-182" java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator;
2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) at org.reflections.Reflections.expandSuperTypes(Reflections.java:380)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.reflections.Reflections.<init>(Reflections.java:126)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.api.ops.factory.DefaultOpFactory.<init>(DefaultOpFactory.java:71)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.Class.newInstance(Class.java:442)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initWithBackend(Nd4j.java:6192)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initContext(Nd4j.java:6087)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.<clinit>(Nd4j.java:201)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at java.lang.Thread.run(Thread.java:748)}}
B) It runs on Mac OS X 10.13.5 with Java 1.8.0_144 without errors.
> Wildfly 13 having wrong version of Maven dependency
> ---------------------------------------------------
>
> Key: WFLY-10742
> URL: https://issues.jboss.org/browse/WFLY-10742
> Project: WildFly
> Issue Type: Bug
> Environment: wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171
> Reporter: Peter K
> Assignee: Jason Greene
>
> I have following Maven dependency in my pom.xml:
> {code:xml}
> <dependency>
> <groupId>com.google.guava</groupId>
> <artifactId>guava</artifactId>
> <version>20.0</version>
> </dependency>
> {code}
> A) When running it on wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171, it is complaining about a missing method in the Guava library (which is a Guava version < 20.0):
> {noformat}
> 2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) Exception in thread "Thread-182" java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator;
> 2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) at org.reflections.Reflections.expandSuperTypes(Reflections.java:380)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.reflections.Reflections.<init>(Reflections.java:126)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.api.ops.factory.DefaultOpFactory.<init>(DefaultOpFactory.java:71)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.Class.newInstance(Class.java:442)
> 2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initWithBackend(Nd4j.java:6192)
> 2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initContext(Nd4j.java:6087)
> 2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.<clinit>(Nd4j.java:201)
> 2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at java.lang.Thread.run(Thread.java:748)}}
> {noformat}
> B) It runs on Mac OS X 10.13.5 with Java 1.8.0_144 without errors.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10742) Wildfly 13 having wrong version of Maven dependency
by Peter K (JIRA)
Peter K created WFLY-10742:
------------------------------
Summary: Wildfly 13 having wrong version of Maven dependency
Key: WFLY-10742
URL: https://issues.jboss.org/browse/WFLY-10742
Project: WildFly
Issue Type: Bug
Environment: wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171
Reporter: Peter K
Assignee: Jason Greene
I have following Maven dependency in my pom.xml:
{{<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>20.0</version>
</dependency>}}
A) When running it on wildfly-13.0.0.Final on Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-119-generic x86_64) with Java 1.8.0_171, it is complaining about a missing method in the Guava library (which is a Guava version < 20.0):
{{2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) Exception in thread "Thread-182" java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator;
2018-07-23 10:43:21,718 ERROR [stderr] (Thread-182) at org.reflections.Reflections.expandSuperTypes(Reflections.java:380)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.reflections.Reflections.<init>(Reflections.java:126)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.api.ops.factory.DefaultOpFactory.<init>(DefaultOpFactory.java:71)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at java.lang.Class.newInstance(Class.java:442)
2018-07-23 10:43:21,719 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initWithBackend(Nd4j.java:6192)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.initContext(Nd4j.java:6087)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at org.nd4j.linalg.factory.Nd4j.<clinit>(Nd4j.java:201)
2018-07-23 10:43:21,720 ERROR [stderr] (Thread-182) at java.lang.Thread.run(Thread.java:748)}}
B) It runs on Mac OS X 10.13.5 with Java 1.8.0_144 without errors.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10607) Fix intermittent failures in RemoteEJBForwardingTestCases
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-10607?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-10607:
--------------------------------------------
(from an older post on a related issue)
I'm looking at this issue at the moment. The issue centers around the operation of the StatefulComponentInstanceInterceptor and the StatefulSessionSynchronizationInterceptor which work together to manage the following: when a method invocation is processed at the server, lookup bean instances from the cache and attach them to the invocation, release those bean instances back to the cache when the invocation has finished, and manage registration of transaction synchronizations if the method is in the scope of a container managed transaction. Actually, a lot more goes on, but its not worth going into in detail. For example, over and above the managed transaction, we have an Infinispan transaction associated with operations get()/put() on the cache which involve the InfinispanBatcher.
The "not in valid state" issue arises when the forwarding node tries to make an invocation on a remote bean and the bean is not found (i.e. NoSuchEJBException is returned as a result of the invocation). What happens here is this: the synchronization interceptor unconditionally calls release() in its finally clause to decrement the usage count of the bean instance which was looked up by the instance interceptor. Under the right conditions, this will case a commit of the Infinispan transaction. Later on, the instance interceptor handles the NoSuchEJBException on the method return by attempting to call discard() on the same bean instance within the same Infinispan transaction ; this fails because the Infinispan transaction has already been committed by the synchronization interceptor.
The fix here is to modify the code in the synchronization interceptor to check if the method invocation return is an exception and if so, do not call release() in that case - we don't want to commit work that is associated with (bad) exceptions. When this is done, the instance interceptor can now successfully call discard() and the problem is resolved.
However, with this fixed, the test still fails with a NoSuchEJBException, which should not happen as there is a live node available in the cluster the forwarding node is sending the invocation to. I'm starting to look into that now.
> Fix intermittent failures in RemoteEJBForwardingTestCases
> ---------------------------------------------------------
>
> Key: WFLY-10607
> URL: https://issues.jboss.org/browse/WFLY-10607
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite
> Reporter: Petr Kremensky
> Assignee: Richard Achmatowicz
>
> The tests were ignored by https://github.com/wildfly/wildfly/pull/10563/files
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3977) Changing multicast address in socket binding does not trigger server to set reload-required
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3977?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFCORE-3977:
----------------------------------------
This should work like other services work, if its service is up it should be put in reload-required state.
Checking the service, it is actually up (jgroups subsystem configuration builders add the dependency):
{noformat}
Service \"org.wildfly.network.socket-binding.jgroups-mping\" (aliases: jboss.binding.jgroups-mping) (class org.jboss.as.server.services.net.SocketBindingService) mode ON_DEMAND state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.network.interface.pr
ivate, org.wildfly.management.socket-binding-manager)
{noformat}
> Changing multicast address in socket binding does not trigger server to set reload-required
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-3977
> URL: https://issues.jboss.org/browse/WFCORE-3977
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 6.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Jeff Mesnil
>
> Found this by accident when debugging a clustering test case.
> If I start a server with profile standalone-full-ha and then modify the multicast address of a clustering related socket-binding, in this case, jgroups-mping, the server is not put into state reload-required.
> This causes a lot of problems in the testsuite which depends on configuring servers after startup and then restarting if necessary to pull in the changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3977) Changing multicast address in socket binding does not trigger server to set reload-required
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3977?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFCORE-3977:
---------------------------------------------
Example: start a server:
{code}
[nrla@localhost bin]$ ./standalone.sh -c standalone-full-ha.xml
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/nrla/projects/wildfly-git-repo-new/dist/target/wildfly-14.0.0.Beta1-SNAPSHOT
JAVA: /opt/jdk-1.8.0_121/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
11:27:56,856 INFO [org.jboss.modules] (main) JBoss Modules version 1.8.5.Final
11:27:57,065 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.2.Final
[snip]
11:28:02,824 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
11:28:02,825 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
11:28:02,825 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
11:28:02,825 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 14.0.0.Beta1-SNAPSHOT (WildFly Core 6.0.0.Alpha3) started in 6223ms - Started 447 of 641 services (407 services are lazy, passive or on-demand)
{code}
make the change in the console:
{code}
nrla@localhost bin]$ ./jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
[standalone@localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=jgroups-mping:write-attribute(name="multicast-address", value="230.0.0.9")
{"outcome" => "success"}
[standalone@localhost:9990 /]
{code}
> Changing multicast address in socket binding does not trigger server to set reload-required
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-3977
> URL: https://issues.jboss.org/browse/WFCORE-3977
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 6.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Jeff Mesnil
>
> Found this by accident when debugging a clustering test case.
> If I start a server with profile standalone-full-ha and then modify the multicast address of a clustering related socket-binding, in this case, jgroups-mping, the server is not put into state reload-required.
> This causes a lot of problems in the testsuite which depends on configuring servers after startup and then restarting if necessary to pull in the changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3977) Changing multicast address in socket binding does not trigger server to set reload-required
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created WFCORE-3977:
-------------------------------------------
Summary: Changing multicast address in socket binding does not trigger server to set reload-required
Key: WFCORE-3977
URL: https://issues.jboss.org/browse/WFCORE-3977
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 6.0.0.Alpha3
Reporter: Richard Achmatowicz
Assignee: Jeff Mesnil
Found this by accident when debugging a clustering test case.
If I start a server with profile standalone-full-ha and then modify the multicast address of a clustering related socket-binding, in this case, jgroups-mping, the server is not put into state reload-required.
This causes a lot of problems in the testsuite which depends on configuring servers after startup and then restarting if necessary to pull in the changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months