April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (REMJMX-92) The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-92?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-92: ----------------------------------- Issue Type: Bug (was: Patch) Fix Version/s: 2.0.1.CR2 > The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check. > ---------------------------------------------------------------------------------------------------- > > Key: REMJMX-92 > URL: https://issues.jboss.org/browse/REMJMX-92 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.1.CR1 > Reporter: Philippe Marschall > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-77) org.jboss.remoting-jmx.timeout is not used when connecting the first time

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-77?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-77: ----------------------------------- Fix Version/s: 2.0.1.CR2 > org.jboss.remoting-jmx.timeout is not used when connecting the first time > ------------------------------------------------------------------------- > > Key: REMJMX-77 > URL: https://issues.jboss.org/browse/REMJMX-77 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.0.Final > Environment: EAP 6.1.1 > Reporter: Osamu Nagano > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > Timeout second is fixed at 5 seconds and not configurable when a client is trying to connect to the server first time. There is a constant "org.jboss.remoting-jmx.timeout" but it is not used here. > https://github.com/jbossas/remoting-jmx/blob/1.1.0.Final/src/main/java/or... > {code} > 207 // open a connection > 208 final IoFuture<Connection> futureConnection = endpoint.connect(convert(serviceUrl), getOptionMap(), handler); > 209 IoFuture.Status result = futureConnection.await(5, TimeUnit.SECONDS); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-92) The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-92?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-92: ----------------------------------- Summary: The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check. (was: Fix HTTPS Protocol) > The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check. > ---------------------------------------------------------------------------------------------------- > > Key: REMJMX-92 > URL: https://issues.jboss.org/browse/REMJMX-92 > Project: Remoting JMX > Issue Type: Patch > Components: Connection > Affects Versions: 2.0.1.CR1 > Reporter: Philippe Marschall > Assignee: Darran Lofthouse > > The HTTPS protocol (https-remoting-jmx) is currently not working because of a broken protocol check. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-95) RemotingConnector violates JMXConnector#connect contract and leads to threads hanging around

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-95?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-95: ----------------------------------- Issue Type: Bug (was: Feature Request) Fix Version/s: 2.0.1.CR2 > RemotingConnector violates JMXConnector#connect contract and leads to threads hanging around > -------------------------------------------------------------------------------------------- > > Key: REMJMX-95 > URL: https://issues.jboss.org/browse/REMJMX-95 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.0.Final > Environment: Wildfly 8.2.0 > Reporter: Sergiy Barlabanov > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > The javadoc of javax.management.remote.JMXConnector#connect says that "If connect has already been called successfully on this object, calling it again has no effect.". > But this does not work with org.jboss.remotingjmx.RemotingConnector. Every connect result in a creation of a remoting endpoint with the corresponding io/worker threads, which are not closed when close() method is called. Only the threads from the first connect() invocation are closed, all threads created from the subsequent connect() invocations are not closed and stay alive until the VM shutdown. > Our application currently crashes after 10 minutes running - it pulls some JMX data periodically and after some time, the VM refuses to create new threads. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-85) Add support for remote:// remote+http:// and remote+https:// URI schemes

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-85?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-85: ----------------------------------- Fix Version/s: 2.0.1.CR2 (was: 2.0.1.Final) > Add support for remote:// remote+http:// and remote+https:// URI schemes > ------------------------------------------------------------------------ > > Key: REMJMX-85 > URL: https://issues.jboss.org/browse/REMJMX-85 > Project: Remoting JMX > Issue Type: Enhancement > Components: Connection > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > Remaining schemes should be deprecated. > Note: Drop the JMX from the scheme as it is redundant. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-4) Allow for long method calls within the protocol.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-4?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated REMJMX-4: ---------------------------------- Fix Version/s: 2.0.2.CR1 (was: 2.0.1.Final) > Allow for long method calls within the protocol. > ------------------------------------------------ > > Key: REMJMX-4 > URL: https://issues.jboss.org/browse/REMJMX-4 > Project: Remoting JMX > Issue Type: Task > Components: Connection, RPC > Reporter: Darran Lofthouse > Fix For: 2.0.2.CR1 > > > Methods such as invoke could take a long time to return depending on what the MBean is actually doing. > This task is to build support for this into the protocol, 2 initial ideas are: - > 1 - Allow the client to 'ping' the server after a request has timed out and ask the server is this request still running, server side the we can track the correlation IDs of current requests an check it is still in-progress. > 2 - The server could periodically send a message to the client to say the message is still in progress, the client could cache these and on timing out check if one has been received recently and wait again if one has. > 3 - Any other suggestions? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-81) Add http-remoting-jmx testing

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-81?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-81: ----------------------------------- Fix Version/s: 2.0.2.CR1 (was: 2.0.1.Final) > Add http-remoting-jmx testing > ----------------------------- > > Key: REMJMX-81 > URL: https://issues.jboss.org/browse/REMJMX-81 > Project: Remoting JMX > Issue Type: Task > Components: Tests > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.2.CR1 > > > Connecting over HTTP is now the default mode for WildFly yet we have no testing of this within the Remoting JMX project itself. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-8) Connection state notification suppport

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-8?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated REMJMX-8: ---------------------------------- Fix Version/s: 2.0.2.CR1 (was: 2.0.1.CR2) > Connection state notification suppport > -------------------------------------- > > Key: REMJMX-8 > URL: https://issues.jboss.org/browse/REMJMX-8 > Project: Remoting JMX > Issue Type: Task > Components: Connection, Notifications > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.2.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-10) Internationalisation of log messages

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-10?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-10: ----------------------------------- Fix Version/s: 2.0.2.CR1 (was: 2.0.1.CR2) > Internationalisation of log messages > ------------------------------------ > > Key: REMJMX-10 > URL: https://issues.jboss.org/browse/REMJMX-10 > Project: Remoting JMX > Issue Type: Task > Reporter: Darran Lofthouse > Fix For: 2.0.2.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4376) Incorrect callback handler used during authentication (SASL)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4376: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=901248 (was: https://bugzilla.redhat.com/show_bug.cgi?id=996897) > Incorrect callback handler used during authentication (SASL) > ------------------------------------------------------------- > > Key: WFLY-4376 > URL: https://issues.jboss.org/browse/WFLY-4376 > Project: WildFly > Issue Type: Bug > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > > Cluster topology messages are not using the proper callbackhandler when the connection is being established. > {code} > 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:187) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87) > ... 7 more > {code} > Before that, this log is produced: > {code} > DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException] > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015