Would this explain things like this in a cluster node log, or am I seeing something else?
2015-04-08 22:22:47,471 INFO [c.c.a.m.ClusteredAgentManagerImpl] (StatsCollector-1:ctx-8f16a26f) SSL: Handshake done 2015-04-08 22:22:47,471 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (StatsCollector-1:ctx-8f16a26f) Connection to peer opened: 345049427801, ip: 10.126.0.2 2015-04-08 22:22:47,471 DEBUG [c.c.a.m.ClusteredAgentAttache] (StatsCollector-1:ctx-8f16a26f) Seq 4-9218586962250694669: Unable to forward null 2015-04-08 22:22:47,471 WARN [c.c.a.m.AgentManagerImpl] (StatsCollector-1:ctx-8f16a26f) Resource [Host:4] is unreachable: Host 4: Unable to reach the peer that the agent is connected -- Erik On Wed, Apr 15, 2015 at 9:20 AM, Marcus <shadow...@gmail.com> wrote: > https://issues.apache.org/jira/browse/CLOUDSTACK-8387 if anyone can take > it. > > On Wed, Apr 15, 2015 at 12:17 AM, Marcus <shadow...@gmail.com> wrote: > > I'm opening a bug, should I assign it to you, or do you know of > > someone who maintains this code? It is probably pretty urgent to go > > out in the next 4.5 bugfix > > > > > > On Wed, Apr 15, 2015 at 12:11 AM, Marcus <shadow...@gmail.com> wrote: > >> Yeah, I backed out the change in my test environment and the issue went > away. > >> > >> On Wed, Apr 15, 2015 at 12:07 AM, Bharat Kumar <bharat.ku...@citrix.com> > wrote: > >>> Hi, > >>> > >>> I guss you are correct. we need to add the newly created channel ch1 > to the map after the handshake is complete. > >>> > >>> _peers.put(peerName, ch) should be changed to _peers.put(peerName, > ch1); > >>> > >>> and also return ch1 instead of ch. > >>> > >>> Thanks, > >>> Bharat. > >>> > >>> > >>> On 15-Apr-2015, at 12:21 pm, Marcus <shadow...@gmail.com> wrote: > >>> > >>>> Is anyone running 4.5 mgmt server in cluster setup? I've run into an > >>>> issue where the channel between the two servers is null, and I think > >>>> I've tracked it down to "coverity fixes" from > >>>> 78bfaa79cf3eaa170ef9422bf8fb1825c0cecfc1. > >>>> > >>>> The method returns 'ch', which is null in the error. The coverity fix > >>>> changes ch for ch1 and seems to initialize ch1 and then drop it on the > >>>> floor. If someone is familiar with this code I'd appreciate a review > >>>> of it. > >>>> > >>>> diff --git > a/engine/orchestration/src/com/cloud/agent/manager/ClusteredAgentManagerImpl.java > >>>> > b/engine/orchestration/src/com/cloud/agent/manager/ClusteredAgentManagerImpl.java > >>>> index 600dca2..e38489b 100755 > >>>> --- > a/engine/orchestration/src/com/cloud/agent/manager/ClusteredAgentManagerImpl.java > >>>> +++ > b/engine/orchestration/src/com/cloud/agent/manager/ClusteredAgentManagerImpl.java > >>>> @@ -498,18 +498,17 @@ public class ClusteredAgentManagerImpl extends > >>>> AgentManagerImpl implements Clust > >>>> } catch (UnknownHostException e) { > >>>> throw new CloudRuntimeException("Unable to > resolve " + ip); > >>>> } > >>>> - try { > >>>> - ch = SocketChannel.open(new > >>>> InetSocketAddress(addr, Port.value())); > >>>> - ch.configureBlocking(true); // make sure we are > >>>> working at blocking mode > >>>> - ch.socket().setKeepAlive(true); > >>>> - ch.socket().setSoTimeout(60 * 1000); > >>>> + try (SocketChannel ch1 = SocketChannel.open(new > >>>> InetSocketAddress(addr, Port.value()));){ > >>>> + ch1.configureBlocking(true); // make sure we are > >>>> working at blocking mode > >>>> + ch1.socket().setKeepAlive(true); > >>>> + ch1.socket().setSoTimeout(60 * 1000); > >>>> try { > >>>> SSLContext sslContext = > Link.initSSLContext(true); > >>>> sslEngine = sslContext.createSSLEngine(ip, > >>>> Port.value()); > >>>> sslEngine.setUseClientMode(true); > >>>> > >>>> > sslEngine.setEnabledProtocols(SSLUtils.getSupportedProtocols(sslEngine.getEnabledProtocols())); > >>>> > >>>> - Link.doHandshake(ch, sslEngine, true); > >>>> + Link.doHandshake(ch1, sslEngine, true); > >>>> s_logger.info("SSL: Handshake done"); > >>>> } catch (Exception e) { > >>>> throw new IOException("SSL: Fail to init SSL! > " + e); > >>> >
