[JBoss JIRA] (WFLY-2869) Incorrect closing of JMS connections causes subsequent tests to fail
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2869?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2869:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1061678|https://bugzilla.redhat.com/show_bug.cgi?id=1061678] from POST to MODIFIED
> Incorrect closing of JMS connections causes subsequent tests to fail
> --------------------------------------------------------------------
>
> Key: WFLY-2869
> URL: https://issues.jboss.org/browse/WFLY-2869
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.0.0.CR1
> Reporter: Jan Martiska
> Assignee: Jan Martiska
>
> RunAsMDBUnitTestCase and GetCallerPrincipalTestCase call stop() to close a JMS connection, which is wrong, it should use close(). This causes the later running AuthenticationTestCase.testAuthentication_ReAuth_ViaServlet (or potentially other tests) to fail due to a timeout, having this in the log:
> {noformat}
> 0m19:53:28,973 INFO [org.jboss.arquillian.testenricher.cdi.container.BeanManagerProducer] (pool-1-thread-1) BeanManager not found.
> [0m[33m19:53:29,218 WARN [org.hornetq.core.client] (Finalizer) HQ212016: I am closing a core ClientSession you left open. Please make sure you close all ClientSessions explicitly before letting them go out of scope! 28,182,273: java.lang.Exception
> at org.hornetq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:91)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:912)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:317)
> at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:648)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:676)
> at org.hornetq.jms.client.HornetQConnectionFactory.createQueueConnection(HornetQConnectionFactory.java:119)
> at org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase.testMDBLifecycle(GetCallerPrincipalTestCase.java:300)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) [:1.7.0_45]
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) [:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) [rt.jar:1.7.0_45]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_45]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) [rt.jar:1.7.0_45]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1469)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:730)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:952)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2592) A server-to-server communication via outbound connection is not working
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-2592?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-2592:
-----------------------------------
The only difference is that it's on a different port. Something like iptables can easily come into play, and it matches your symptoms pretty much exactly, so that would be the first thing to check - the TCP retransmits seem to indicate that the network layer isn't even getting the packets, long before WildFly or EAP would have a chance to touch the data.
> A server-to-server communication via outbound connection is not working
> -----------------------------------------------------------------------
>
> Key: WFLY-2592
> URL: https://issues.jboss.org/browse/WFLY-2592
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Remoting
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
> Labels: ejb, remoting
> Attachments: networktraffic, server-client.log, server-server.log
>
>
> A ejb invocation from a SLSB is configured similar to AS7 (EAP6) to call a remote server fail in WildFly with the ERROR message " EJBCLIENT000025: No EJB receiver available for handling".
> The logfiles of client(server) and remote-server are attached, also a WireShark dump of the related network traffic.
> A standalone client at the same machine is able to call the remote application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2873) TestParser cannot marshal empty subsystems
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-2873:
--------------------------------------
Summary: TestParser cannot marshal empty subsystems
Key: WFLY-2873
URL: https://issues.jboss.org/browse/WFLY-2873
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management, Test Suite
Affects Versions: 8.0.0.CR1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 8.0.0.Final
TestParser (used in subsystem test framework) will only marshal if the subsystem's ModelNode isDefined(). But for simple subsystems with no attributes it doesn't have to be defined.
It should just check for node existence -- parentNode.has(subsystemName) -- not whether the node is defined.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2760) Intermittent failure of ExternalContextBindingTestCase
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2760?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2760:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1061618|https://bugzilla.redhat.com/show_bug.cgi?id=1061618] from POST to MODIFIED
> Intermittent failure of ExternalContextBindingTestCase
> -------------------------------------------------------
>
> Key: WFLY-2760
> URL: https://issues.jboss.org/browse/WFLY-2760
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.0.0.CR1
> Reporter: Jan Martiska
> Assignee: Jan Martiska
> Priority: Minor
>
> The server setup task sometimes fails to start the ApacheDS server instance because for some reason, BouncyCastle security provider doesn't get registered (it is added through a maven dependency rather than added to the JDK). This leads to a "connection refused" error during the test when it is trying to connect to the LDAP instance.
> It worked for us if we just programatically forced registration of the BouncyCastleProvider before the initialization of ApacheDS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (WFLY-2319) LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2319:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1061181|https://bugzilla.redhat.com/show_bug.cgi?id=1061181] from POST to MODIFIED
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2319
> URL: https://issues.jboss.org/browse/WFLY-2319
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Beta1
> Reporter: Darran Lofthouse
> Assignee: Eduardo Martins
> Fix For: 8.0.0.CR1
>
> Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
> Hashtable env = new Hashtable();
> env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
> env.put("java.naming.security.authentication", "simple");
> env.put("java.naming.provider.url", "ldap://localhost:10389");
> env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
> env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
> SearchControls ctl = null;
> String attrArr[] = new String[1];
> attrArr[0] = "sn";
> ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
> String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
> String filter = "(uid=UserOne)";
> NamingEnumeration nenum = null;
> DirContext ictx = null;
> ictx = new InitialDirContext(env);
> nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
> protected Context getURLOrDefaultInitCtx(String name)
> throws NamingException {
> if (NamingManager.hasInitialContextFactoryBuilder()) {
> return getDefaultInitCtx();
> }
> String scheme = getURLScheme(name);
> if (scheme != null) {
> Context ctx = NamingManager.getURLContext(scheme, myProps);
> if (ctx != null) {
> return ctx;
> }
> }
> return getDefaultInitCtx();
> }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months