March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10016) HTTP + EJB - UnsupportedOperationException trying to write to an AbstractMap

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10016?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFLY-10016. ------------------------------------- Fix Version/s: 13.0.0.Beta1 Resolution: Done > HTTP + EJB - UnsupportedOperationException trying to write to an AbstractMap > ---------------------------------------------------------------------------- > > Key: WFLY-10016 > URL: https://issues.jboss.org/browse/WFLY-10016 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Brian Stansberry > Assignee: Stuart Douglas > Fix For: 13.0.0.Beta1 > > > [~tremes] Has hit this failure when running some tests against our OpenShift images using WF code from, I believe, 12 CR1. > {code} > 13:03:50,832 ERROR [org.jboss.as.ejb3.remote] (default task-1) WFLYEJB0150: Could not write method invocation failure for method public abstract void com.redhat.xpaas.ejb.server.RemoteCounter.increment() on bean named CounterBean for appname modulename ROOT distinctname due to: java.lang.UnsupportedOperationException > at java.util.AbstractMap.put(AbstractMap.java:209) > at org.jboss.as.ejb3.remote.AssociationImpl.updateAffinities(AssociationImpl.java:267) > at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:233) > 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) > {code} > He or [~luck3y] can give you more details re the specific test. > Just walking through code, my guess is the Collections.emptyMap() produced at [1] is getting passed through the stack to the failing code. (I'm filing this because I did this bit of brilliant analysis. ;) ) > [1] https://github.com/wildfly/wildfly-http-client/blob/master/ejb/src/main/j... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10026) *WebFailoverTestCase-s fail frequently on Windows

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10026?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-10026: ----------------------------------------- I merged https://github.com/wildfly/wildfly/pull/11010 but I'm not resolving this as I didn't interpret that as the fix, just the @Ignore. > *WebFailoverTestCase-s fail frequently on Windows > ------------------------------------------------- > > Key: WFLY-10026 > URL: https://issues.jboss.org/browse/WFLY-10026 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: No Release > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Observed failures: > * node3 never joins the cluster > * "waiting for responses from node-1" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10038) WildFly 12 Welcome page still displays "Welcome to WildFly 11"

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-10038?page=com.atlassian.jira.plugin... ] jaikiran pai resolved WFLY-10038. --------------------------------- Resolution: Duplicate Issue This is indeed a bug and was recently fixed as part of https://issues.jboss.org/browse/WFLY-9947 > WildFly 12 Welcome page still displays "Welcome to WildFly 11" > -------------------------------------------------------------- > > Key: WFLY-10038 > URL: https://issues.jboss.org/browse/WFLY-10038 > Project: WildFly > Issue Type: Bug > Reporter: Francesco Marchioni > Assignee: Jason Greene > Priority: Minor > > Just Install WildFly 12 and land on the home page. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3302) Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3302?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-3302: ------------------------------------- Here's the update. (Very) long story made (very) short, this may be due to a known NIO bug. If a server is created and asynchronously closed in very rapid succession, NIO may inadvertently call bind() on a completely different socket, potentially leaving a zombie occupying the port. This is the first plausible explanation that I've been able to discover for this behavior, or for why the workaround in XNIO (where we cancel the selection key from every selector before returning from close) makes the race go away. I think it's safe to call this "fixed" since we haven't seen it again, and our observations and the known facts seem to fit together. But it's not really "fixed", just "worked around" (until Java 11 where a proper fix is present). > Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5 > --------------------------------------------------------------------------------------------- > > Key: WFCORE-3302 > URL: https://issues.jboss.org/browse/WFCORE-3302 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > > This bug is about problems in WF Core management tests. I believe it exposes a flaw in how remoting handles server sockets, but AFAIK there is no impact on WF Core remoting server sockets. > Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet: > {code} > java.lang.RuntimeException: java.net.BindException: Address already in use: bind > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282) > at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372) > at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92) > at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88) > at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94) > at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346) > {code} > These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests. > I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method. > The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens: > {code} > "XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307) > - locked <0xc0d> (a java.lang.Object) > at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229) > at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) > - locked <0xc38> (a java.util.HashSet) > at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl) > - locked <0xc39> (a java.util.Collections$UnmodifiableSet) > - locked <0xc3a> (a sun.nio.ch.Util$2) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:519) > {code} > That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket. > I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed. > I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3695) Tests using ByteMan are corrupting the surefire plugin command stream

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3695?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-3695: ------------------------------------- For an example, see https://ci.wildfly.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug... > Tests using ByteMan are corrupting the surefire plugin command stream > --------------------------------------------------------------------- > > Key: WFCORE-3695 > URL: https://issues.jboss.org/browse/WFCORE-3695 > Project: WildFly Core > Issue Type: Bug > Reporter: David Lloyd > > The symptom is a message like: > {noformat} > 2018-03-16 17:04:37 [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file /xxxx/wildfly-core/deployment-repository/target/surefire-reports/2018-03-16T17-03-30_598-jvmRun1.dumpstream > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3695) Tests using ByteMan are corrupting the surefire plugin command stream

by David Lloyd (JIRA)

David Lloyd created WFCORE-3695: ----------------------------------- Summary: Tests using ByteMan are corrupting the surefire plugin command stream Key: WFCORE-3695 URL: https://issues.jboss.org/browse/WFCORE-3695 Project: WildFly Core Issue Type: Bug Reporter: David Lloyd The symptom is a message like: {noformat} 2018-03-16 17:04:37 [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file /xxxx/wildfly-core/deployment-repository/target/surefire-reports/2018-03-16T17-03-30_598-jvmRun1.dumpstream {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-65) [QE] SWS-158

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-65?page=com.atlassian.jira.plugin.s... ] Matt Mahoney reassigned SWSQE-65: --------------------------------- Assignee: Matt Mahoney (was: Michael Foley) > [QE] SWS-158 > ------------ > > Key: SWSQE-65 > URL: https://issues.jboss.org/browse/SWSQE-65 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Matt Mahoney > > View information about a service on the service graph > [link title|https://issues.jboss.org/browse/SWS-158] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-66) [QE] SWS-160

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-66?page=com.atlassian.jira.plugin.s... ] Guilherme Baufaker Rêgo reassigned SWSQE-66: -------------------------------------------- Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > [QE] SWS-160 > ------------ > > Key: SWSQE-66 > URL: https://issues.jboss.org/browse/SWSQE-66 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > View information about a versioned service on the service graph > [link title|https://issues.jboss.org/browse/SWS-160] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-67) [QE] SWS-166

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-67?page=com.atlassian.jira.plugin.s... ] Guilherme Baufaker Rêgo reassigned SWSQE-67: -------------------------------------------- Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > [QE] SWS-166 > ------------ > > Key: SWSQE-67 > URL: https://issues.jboss.org/browse/SWSQE-67 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Select the time span for the Service Graph page > [link title|https://issues.jboss.org/browse/SWS-166] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-64) [QE] SWS-226

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-64?page=com.atlassian.jira.plugin.s... ] Matt Mahoney reassigned SWSQE-64: --------------------------------- Assignee: Matt Mahoney (was: Michael Foley) > [QE] SWS-226 > ------------ > > Key: SWSQE-64 > URL: https://issues.jboss.org/browse/SWSQE-64 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Matt Mahoney > > Report SWS version and status information to users > [link title|https://issues.jboss.org/browse/SWS-226] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2018