January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall

by George Turner (JIRA)

[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ] George Turner commented on WFLY-4769: ------------------------------------- Is this code "compatible" with WildFly 10 and the Artemis JMS now? Do you have an updated example. Our workaround was actually on the client side, but I would prefer this style if doable. Sorry the CutAndPaste did not hold formatting. public static void fixConnectionFactory(final ConnectionFactory cf, final String host) { try { Method m = findMethodByName(cf.getClass(), "getServerLocator"); if (m != null) { Object serverLocator = m.invoke(cf); Method getTransportConfigs = findMethodByName(serverLocator.getClass(), "getStaticTransportConfigurations"); if (getTransportConfigs != null) { Object transportConfigs = getTransportConfigs.invoke(serverLocator); Object firstConfig = Array.get(transportConfigs, 0); Method getParams = findMethodByName(firstConfig.getClass(), "getParams"); if (getParams != null) { Object params = getParams.invoke(firstConfig); Method put = findMethodByName(params.getClass(), "put", "String", "String"); if (put != null) { put.invoke(params, "host", host); } } } } } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) { // Really shouldn't ever happen e.printStackTrace(); } } private static Method findMethodByName(Class<?> class1, String name, String... argTypeNames) { for (Method m : class1.getMethods()) { if (m.getName().equals(name) && m.getParameterTypes().length == argTypeNames.length) { return m; } } return null; } > WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4769 > URL: https://issues.jboss.org/browse/WFLY-4769 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.2.0.Final, 9.0.0.CR1 > Environment: RedHat7 > Reporter: George Turner > Assignee: Jeff Mesnil > > Server is behind NAT firewall. Client code: > Properties topicProperties = new Properties(); > topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); > topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port); > InitialContext ctx = new InitialContext(topicProperties); > ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory"); > connection = tmp.createConnection(); > Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit> > INFO: XNIO version 3.3.1.Final > Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit> > INFO: XNIO NIO Implementation Version 3.3.1.Final > Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit> > INFO: JBoss Remoting version 4.0.9.Final > javax.jms.JMSException: Failed to create session factory > at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673) > at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112) > at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107) > at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36) > at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24) > Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.] > at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905) > at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669) > ... 4 more > Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket' > > Client debugger shows the ConnectionFactory instance returned: > initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183} > 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor" > name = {java.lang.String@2198} "http-connector" > factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory" > params = {java.util.HashMap@2200} size = 4 > 0 = {java.util.HashMap$Node@2203} "port" -> "8080" > 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77" > 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true" > 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor" > 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1289) installing CP over one-off fails if the modules patched by the one-off are not patched in the CP

by Brad Maxwell (JIRA)

Brad Maxwell created WFCORE-1289: ------------------------------------ Summary: installing CP over one-off fails if the modules patched by the one-off are not patched in the CP Key: WFCORE-1289 URL: https://issues.jboss.org/browse/WFCORE-1289 Project: WildFly Core Issue Type: Bug Components: Patching Affects Versions: 1.0.1.Final Reporter: Brad Maxwell Assignee: Alexey Loubyansky Priority: Critical If a CP is installed over active one-off patches, the patch application may fail if the CP does not contain updates for the modules that were patched by the one-offs. Normally, CP patches accumulate the one-off patches released since the previous CP which is, probably, why this bug has not been discovered for a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1288) installing CP over one-off fails if the modules patched by the one-off are not patched in the CP

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1288?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration updated WFCORE-1288: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1295999 Bugzilla Update: Perform > installing CP over one-off fails if the modules patched by the one-off are not patched in the CP > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1288 > URL: https://issues.jboss.org/browse/WFCORE-1288 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.1.Final > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Priority: Critical > > If a CP is installed over active one-off patches, the patch application may fail if the CP does not contain updates for the modules that were patched by the one-offs. > Normally, CP patches accumulate the one-off patches released since the previous CP which is, probably, why this bug has not been discovered for a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-149) Failures in 'resolve-expression" op appear in server log

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-149?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet updated WFCORE-149: ------------------------------------- Summary: Failures in 'resolve-expression" op appear in server log (was: Failues in 'resolve-expression" op appear in server log) > Failures in 'resolve-expression" op appear in server log > -------------------------------------------------------- > > Key: WFCORE-149 > URL: https://issues.jboss.org/browse/WFCORE-149 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > > I happened to notice this in a server log: > 11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}" > That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation. > A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value. > Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-149) Failures in 'resolve-expression" op appear in server log

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-149?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet reassigned WFCORE-149: ---------------------------------------- Assignee: ehsavoie Hugonnet > Failures in 'resolve-expression" op appear in server log > -------------------------------------------------------- > > Key: WFCORE-149 > URL: https://issues.jboss.org/browse/WFCORE-149 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Priority: Minor > > I happened to notice this in a server log: > 11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}" > That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation. > A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value. > Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5766) ManagedExecutorService's max-threads attribute is not honored if an unbounded queue is used

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-5766?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-5766: ----------------------------------- Assignee: James Perkins (was: Eduardo Martins) > ManagedExecutorService's max-threads attribute is not honored if an unbounded queue is used > ------------------------------------------------------------------------------------------- > > Key: WFLY-5766 > URL: https://issues.jboss.org/browse/WFLY-5766 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 10.0.0.CR4 > Reporter: Jan Martiska > Assignee: James Perkins > > If you set a max-threads attribute to a managed-executor-service and the number is higher than core-threads, and its queue is unbounded (queue-length is undefined), it won't use any more threads than the number from core-threads. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1288) installing CP over one-off fails if the modules patched by the one-off are not patched in the CP

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1288?page=com.atlassian.jira.plugi... ] Alexey Loubyansky moved JBEAP-2668 to WFCORE-1288: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1288 (was: JBEAP-2668) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Patching (was: Patching) Target Release: (was: 7.0.0.GA) Affects Version/s: 1.0.1.Final (was: 6.4.0.GA) > installing CP over one-off fails if the modules patched by the one-off are not patched in the CP > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-1288 > URL: https://issues.jboss.org/browse/WFCORE-1288 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.1.Final > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Priority: Critical > > If a CP is installed over active one-off patches, the patch application may fail if the CP does not contain updates for the modules that were patched by the one-offs. > Normally, CP patches accumulate the one-off patches released since the previous CP which is, probably, why this bug has not been discovered for a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5927) Transformation tests that were failing due to WFCORE-1210 are still disabled

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5927?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5927: --------------------------------- Summary: Transformation tests that were failing due to WFCORE-1210 are still disabled (was: Enable transformation tests failing due to WFCORE-1210) > Transformation tests that were failing due to WFCORE-1210 are still disabled > ---------------------------------------------------------------------------- > > Key: WFLY-5927 > URL: https://issues.jboss.org/browse/WFLY-5927 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Alias addresses tests in {{org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase#propertiesMapOperationsTest}} were affected by WFCORE-1210. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5927) Enable transformation tests failing due to WFCORE-1210

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5927?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5927: --------------------------------- Issue Type: Bug (was: Task) > Enable transformation tests failing due to WFCORE-1210 > ------------------------------------------------------ > > Key: WFLY-5927 > URL: https://issues.jboss.org/browse/WFLY-5927 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Alias addresses tests in {{org.jboss.as.clustering.infinispan.subsystem.TransformersTestCase#propertiesMapOperationsTest}} were affected by WFCORE-1210. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5519) Some clustering tests fail with security manager

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5519?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5519: --------------------------------- Summary: Some clustering tests fail with security manager (was: Some clustering tests fails with security manager) > Some clustering tests fail with security manager > ------------------------------------------------ > > Key: WFLY-5519 > URL: https://issues.jboss.org/browse/WFLY-5519 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 10.0.0.CR2 > Reporter: Marek Kopecký > Assignee: Radoslav Husar > Attachments: clustering.secman.zip > > > *Description of problem:* > Some clustering tests fails with security manager. Affected testcases: > {noformat}org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase(SYNC-tcp).testGracefulUndeployFailover > org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase(SYNC-tcp).testGracefulSimpleFailover > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).failoverOnStop > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).nestedBeanFailover > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).connectionFactoryFailover > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).jmsConnectionFactoryFailover > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).noFailover > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).simpleFailover > org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase(SYNC-tcp).timeout > org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase(SYNC-tcp).testBasicXPC > org.jboss.as.test.clustering.cluster.ejb.xpc.StatefulWithXPCFailoverTestCase(SYNC-tcp).testSecondLevelCache > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.singleton.SingletonServiceTestCase(SYNC-tcp).testSingletonService > org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase(SYNC-tcp).testFormAuthSingleSignOn > org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testSerialized > org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testSessionReplication > org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testGracefulServeOnUndeploy > org.jboss.as.test.clustering.cluster.web.ClusteredWebSimpleTestCase(SYNC-tcp).testGracefulServeOnShutdown > org.jboss.as.test.clustering.cluster.web.ExternalizerTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.web.ReplicationForNegotiationAuthenticatorTestCase(SYNC-tcp).testOneRequestSimpleFailover > org.jboss.as.test.clustering.cluster.web.async.AsyncServletTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.web.context.InvalidateConversationTestCase(SYNC-tcp).testInvalidate > org.jboss.as.test.clustering.cluster.web.expiration.CoarseSessionExpirationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.web.expiration.FineSessionExpirationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.web.passivation.CoarseSessionPassivationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.web.passivation.FineSessionPassivationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.web.shared.SharedSessionFailoverTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.single.registry.RegistryTestCase.org.jboss.as.test.clustering.single.registry.RegistryTestCase > org.jboss.as.test.clustering.single.singleton.SingletonServiceTestCase.org.jboss.as.test.clustering.single.singleton.SingletonServiceTestCase{noformat} > *How reproducible:* > Always > *Steps to Reproduce:* > # ./integration-tests.sh -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Djboss.dist=$JBOSS_DIST -Dsecurity.manager -Dts.clustering -Dts.noSmoke > *Actual results:* > See attached logs > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 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 January 2016