[JBoss JIRA] (WFCORE-774) Memory leak in JBoss CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-774?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-774:
------------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1232736|https://bugzilla.redhat.com/show_bug.cgi?id=1232736] from ON_QA to VERIFIED
> Memory leak in JBoss CLI
> ------------------------
>
> Key: WFCORE-774
> URL: https://issues.jboss.org/browse/WFCORE-774
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.CR6, 2.0.0.Alpha4
> Reporter: Josef Cacek
> Assignee: Tomas Hofman
>
> The JBoss CLI contains a memory leak related to CLI Kerberos authentication.
> The {{org.jboss.as.cli.impl.CommandContextImpl}} class calls the {{initJaasConfig()}} in its constructor,
> which adds a new {{JaasConfigurationWrapper}} instance to {{javax.security.auth.login.Configuration}}.
> It's done for every new {{CommandContext}} instance, so it consumes more and more memory. There is no cleanup for the registered
> configurations.
> Moreover, the searches for appropriate
> login config take more and more time because they have to go through all the wrapped objects.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1946) Auth succeeds when the node without auth starts first
by fatih fatih (JIRA)
[ https://issues.jboss.org/browse/JGRP-1946?page=com.atlassian.jira.plugin.... ]
fatih fatih updated JGRP-1946:
------------------------------
Description:
Node starts without auth it becomes coordinator of its cluster
In the same cluster another node starts with X509 Auth
The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
The purpose is not to allow the nodes that is with auth and the nodes that is without auth to join with each other.
was:
Node starts without auth it becomes coordinator of its cluster
In the same cluster another node starts with X509 Auth
The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
> Auth succeeds when the node without auth starts first
> -----------------------------------------------------
>
> Key: JGRP-1946
> URL: https://issues.jboss.org/browse/JGRP-1946
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.6.4
> Environment: jdk 1.7
> Reporter: fatih fatih
> Assignee: Bela Ban
> Attachments: HAController2.java, udp.xml, udp.xml
>
>
> Node starts without auth it becomes coordinator of its cluster
> In the same cluster another node starts with X509 Auth
> The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
> The purpose is not to allow the nodes that is with auth and the nodes that is without auth to join with each other.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1946) Auth succeeds when the node without auth starts first
by fatih fatih (JIRA)
[ https://issues.jboss.org/browse/JGRP-1946?page=com.atlassian.jira.plugin.... ]
fatih fatih updated JGRP-1946:
------------------------------
Attachment: udp.xml
HAController2.java
udp.xml
one of the udp.xml does not include AUTH property
> Auth succeeds when the node without auth starts first
> -----------------------------------------------------
>
> Key: JGRP-1946
> URL: https://issues.jboss.org/browse/JGRP-1946
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.6.4
> Environment: jdk 1.7
> Reporter: fatih fatih
> Assignee: Bela Ban
> Attachments: HAController2.java, udp.xml, udp.xml
>
>
> Node starts without auth it becomes coordinator of its cluster
> In the same cluster another node starts with X509 Auth
> The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1946) Auth succeeds when the node without auth starts first
by fatih fatih (JIRA)
fatih fatih created JGRP-1946:
---------------------------------
Summary: Auth succeeds when the node without auth starts first
Key: JGRP-1946
URL: https://issues.jboss.org/browse/JGRP-1946
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.6.4
Environment: jdk 1.7
Reporter: fatih fatih
Assignee: Bela Ban
Node starts without auth it becomes coordinator of its cluster
In the same cluster another node starts with X509 Auth
The node starting with auth succeeds to join to the cluster that is started by the first node instead of creating its own cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (DROOLS-795) Timers are reset during the serialization process
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-795?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-795:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1248429|https://bugzilla.redhat.com/show_bug.cgi?id=1248429] from NEW to ASSIGNED
> Timers are reset during the serialization process
> -------------------------------------------------
>
> Key: DROOLS-795
> URL: https://issues.jboss.org/browse/DROOLS-795
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR1
>
>
> When the marshall serializes a timer it doesn't take count of how much time it is already passed, so when the timer is deserialized it restart from it start time. The following failing test case reproduces the problem.
> {code}
> @Test
> public void testMarshallWithTimedRule() {
> String drl = "rule \"Rule A Timeout\"\n" +
> "when\n" +
> " String( this == \"ATrigger\" )\n" +
> "then\n" +
> " insert (new String( \"A-Timer\") );\n" +
> "System.out.println(\"+++++++Got ATrigger, started A-Timer with 5s timeout\");\n" +
> "end\n" +
> "\n" +
> "rule \"Timer For rule A Timeout\"\n" +
> " timer ( int: 5s )\n" +
> "when\n" +
> " String( this == \"A-Timer\")\n" +
> "then\n" +
> " delete ( \"A-Timer\" );\n" +
> " delete ( \"ATrigger\" );\n" +
> "System.out.println(\"******* reset rule A based on timer\");\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL )
> .build( EqualityBehaviorOption.EQUALITY,
> DeclarativeAgendaOption.ENABLED,
> EventProcessingOption.STREAM );
> KieSessionConfiguration sessionConfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> sessionConfig.setOption( ClockTypeOption.get( "pseudo" ) );
> KieSession ksession = kbase.newKieSession(sessionConfig, null);
> ksession.insert( new String( "ATrigger" ) );
> assertEquals( 1, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> ksession = marshallAndUnmarshall( kbase, ksession, sessionConfig);
> clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 0, ksession.getFactCount() );
> }
> public static KieSession marshallAndUnmarshall(KieBase kbase, KieSession ksession, KieSessionConfiguration sessionConfig) {
> // Serialize and Deserialize
> try {
> Marshaller marshaller = KieServices.Factory.get().getMarshallers().newMarshaller(kbase);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> marshaller.marshall(baos, ksession);
> marshaller = MarshallerFactory.newMarshaller( kbase );
> ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
> baos.close();
> ksession = marshaller.unmarshall(bais, sessionConfig, null);
> bais.close();
> } catch (Exception e) {
> e.printStackTrace();
> fail("unexpected exception :" + e.getMessage());
> }
> return ksession;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (AS7-6911) jconsole fails if trying to connect to a standalone EAP instance running with offset ports
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6911?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6911:
----------------------------------------------
Marek Kopecky <mkopecky(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from ON_QA to ASSIGNED
> jconsole fails if trying to connect to a standalone EAP instance running with offset ports
> ------------------------------------------------------------------------------------------
>
> Key: AS7-6911
> URL: https://issues.jboss.org/browse/AS7-6911
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Stan Silvert
> Labels: cli
>
> If JBoss AS7/8 is started using port-offset as following:
> ie. with -Djboss.socket.binding.port-offset=100
> Then While connecting to it using "jconsole.sh" as a Local Process it throws the following Exception:
> +++++++++++++++++++++++++++++
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
> at java.awt.EventQueue.access$000(EventQueue.java:84)
> at java.awt.EventQueue$1.run(EventQueue.java:607)
> at java.awt.EventQueue$1.run(EventQueue.java:605)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> +++++++++++++++++++++++
> And the Code "org.jboss.as.cli.gui.JConsoleCLIPlugin" classes Line 109 throws NullPointerException, Because "cliGuiCtx" object is null and not initialized earlier:
> 109 JOptionPane.showMessageDialog(cliGuiCtx.getMainWindow(), message);
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-5037) The infinispan-directory-provider jar is packaged in multiple modules
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-5037:
----------------------------------
Summary: The infinispan-directory-provider jar is packaged in multiple modules
Key: WFLY-5037
URL: https://issues.jboss.org/browse/WFLY-5037
Project: WildFly
Issue Type: Bug
Components: Clustering, JPA / Hibernate
Affects Versions: 10.0.0.Alpha6
Reporter: Hynek Švábek
Assignee: Sanne Grinovero
Priority: Minor
The module integrating Infinispan storage for Hibernate Search indexes is currently duplicated, as a result of a rename of the project ownership and it being moved from Hibernate to Infinispan for maintenance, and not all dependencies being in synch yet.
This problem might be resolved by the move to feature packs, but creating this issue to make sure of that.
As far as I know the problem doesn't result in any lack of functionality, other than taking some unnecessary space.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-5036) The infinispan-directory-provider jar is packaged in multiple modules
by Sanne Grinovero (JIRA)
Sanne Grinovero created WFLY-5036:
-------------------------------------
Summary: The infinispan-directory-provider jar is packaged in multiple modules
Key: WFLY-5036
URL: https://issues.jboss.org/browse/WFLY-5036
Project: WildFly
Issue Type: Bug
Components: Clustering, JPA / Hibernate
Affects Versions: 10.0.0.Alpha6
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Priority: Minor
The module integrating Infinispan storage for Hibernate Search indexes is currently duplicated, as a result of a rename of the project ownership and it being moved from Hibernate to Infinispan for maintenance, and not all dependencies being in synch yet.
This problem might be resolved by the move to feature packs, but creating this issue to make sure of that.
As far as I know the problem doesn't result in any lack of functionality, other than taking some unnecessary space.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4936) JGroups: failed setting ip_ttl on windows with IPv6
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4936?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-4936:
---------------------------------
Description:
-The org.jboss.as.test.clustering.messaging.ClusteredMessagingTestCase.testClusteredQueue test fails on our CI[1].-
The messaging resources are using the udp stack from JGroups but JGroups logs a SEVERE message:
{noformat}
10:18:14,721 SEVERE [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=34818b2c-2b93-11e5-aeb7-199c6bd1db3c-31443612)) failed setting ip_ttl: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
at org.jgroups.protocols.UDP.start(UDP.java:270)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
at org.jgroups.JChannel.startStack(JChannel.java:891)
at org.jgroups.JChannel._preConnect(JChannel.java:553)
at org.jgroups.JChannel.connect(JChannel.java:288)
at org.jgroups.JChannel.connect(JChannel.java:279)
at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211)
at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115)
at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openClient(JGroupsBroadcastEndpoint.java:92)
at org.apache.activemq.artemis.core.cluster.DiscoveryGroup.start(DiscoveryGroup.java:105)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialise(ServerLocatorImpl.java:380)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:846)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:687)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:671)
at org.apache.activemq.artemis.core.server.cluster.ClusterController$ConnectRunnable.run(ClusterController.java:448)
at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Method not implemented!
at java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:236)
... 25 more
{noformat}
-I'm not sure whether this is the root cause of the failure but there looks to be an issue with setting up the UDP stack on our CI.-
[1] http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=60815&buildTyp...
was:
The org.jboss.as.test.clustering.messaging.ClusteredMessagingTestCase.testClusteredQueue test fails on our CI[1].
The messaging resources are using the udp stack from JGroups but JGroups logs a SEVERE message:
{noformat}
10:18:14,721 SEVERE [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=34818b2c-2b93-11e5-aeb7-199c6bd1db3c-31443612)) failed setting ip_ttl: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
at org.jgroups.protocols.UDP.start(UDP.java:270)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
at org.jgroups.JChannel.startStack(JChannel.java:891)
at org.jgroups.JChannel._preConnect(JChannel.java:553)
at org.jgroups.JChannel.connect(JChannel.java:288)
at org.jgroups.JChannel.connect(JChannel.java:279)
at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211)
at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115)
at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openClient(JGroupsBroadcastEndpoint.java:92)
at org.apache.activemq.artemis.core.cluster.DiscoveryGroup.start(DiscoveryGroup.java:105)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialise(ServerLocatorImpl.java:380)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:846)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:687)
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:671)
at org.apache.activemq.artemis.core.server.cluster.ClusterController$ConnectRunnable.run(ClusterController.java:448)
at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Method not implemented!
at java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:236)
... 25 more
{noformat}
I'm not sure whether this is the root cause of the failure but there looks to be an issue with setting up the UDP stack on our CI.
[1] http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=60815&buildTyp...
> JGroups: failed setting ip_ttl on windows with IPv6
> ---------------------------------------------------
>
> Key: WFLY-4936
> URL: https://issues.jboss.org/browse/WFLY-4936
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Jeff Mesnil
> Assignee: Radoslav Husar
> Priority: Minor
>
> -The org.jboss.as.test.clustering.messaging.ClusteredMessagingTestCase.testClusteredQueue test fails on our CI[1].-
> The messaging resources are using the udp stack from JGroups but JGroups logs a SEVERE message:
> {noformat}
> 10:18:14,721 SEVERE [org.jgroups.protocols.UDP] (Thread-0 (ActiveMQ-server-ActiveMQServerImpl::serverUUID=34818b2c-2b93-11e5-aeb7-199c6bd1db3c-31443612)) failed setting ip_ttl: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:368)
> at org.jgroups.protocols.UDP.start(UDP.java:270)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:891)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint$JChannelWrapper.connect(JGroupsBroadcastEndpoint.java:211)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.internalOpen(JGroupsBroadcastEndpoint.java:115)
> at org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint.openClient(JGroupsBroadcastEndpoint.java:92)
> at org.apache.activemq.artemis.core.cluster.DiscoveryGroup.start(DiscoveryGroup.java:105)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.initialise(ServerLocatorImpl.java:380)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:846)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:687)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:671)
> at org.apache.activemq.artemis.core.server.cluster.ClusterController$ConnectRunnable.run(ClusterController.java:448)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Method not implemented!
> at java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:236)
> ... 25 more
> {noformat}
> -I'm not sure whether this is the root cause of the failure but there looks to be an issue with setting up the UDP stack on our CI.-
> [1] http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=60815&buildTyp...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months