this connection strategy is too aggressive, in other words it's attempting to try too frequently to reconnect and causing saturation on clients firewall

case MULTI_THREADED_BUSY_WAITING:
                return HandlerPriority.BLOCKING;

This is terribly wrong.

This creates unnecessary lambda instantiations for calls with two or more parameters.

While trying to use ChronicleEngine to access a queue remotely, we occasionally see the following AssertionError (once every few runs):

524748  [1, Demo Asset remote]
2017-02-06T16:43:18.847 /TcpChannelHub-Reads-(none) TcpSocketConsumer java.lang.AssertionError: Found tid=1486392198574 in the old map.
        at net.openhft.chronicle.network.connection.TcpChannelHub$TcpSocketConsumer.processData(TcpChannelHub.java:1346)
        at net.openhft.chronicle.network.connection.TcpChannelHub$TcpSocketConsumer.running(TcpChannelHub.java:1231)
        at net.openhft.chronicle.network.connection.TcpChannelHub$TcpSocketConsumer.lambda$start$3(TcpChannelHub.java:1160)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        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)

and sometimes (not always) it is then immediately followed in the logs by this:

525660  [2, Demo Asset remote]
2017-02-06T16:43:18.852 tree-1/conc-event-loop-0 TcpEventHandler java.io.IOException: Broken pipe
        at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
        at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
        at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
        at sun.nio.ch.IOUtil.write(IOUtil.java:51)
        at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
        at net.openhft.chronicle.network.TcpEventHandler.tryWrite(TcpEventHandler.java:332)
        at net.openhft.chronicle.network.TcpEventHandler.invokeHandler(TcpEventHandler.java:253)
        at net.openhft.chronicle.network.TcpEventHandler.action(TcpEventHandler.java:183)
        at net.openhft.chronicle.threads.VanillaEventLoop.runAllMediumHandler(VanillaEventLoop.java:286)
        at net.openhft.chronicle.threads.VanillaEventLoop.run(VanillaEventLoop.java:206)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        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)

After the assertion error (with or without the IOException) the logs are silent for a few seconds, and then there is what appears to be a loop of acquires and releases (onAcquired/onReleased callbacks) that never stops.

Being an assertion, I take it to mean it's a code error that should never occur, but the cryptic message doesn't help much in understanding what the issue is... we hope it means something to you and can be fixed soon :-)

Hi there,
I'm trying to leverage chronicle network to build a bidirectional communication channel, both side need the ability to send request to the other side and wait reply, could you help to build a sample on how to push data from server to client (TcpChannelHub) or give some suggestions on how to do it.

Thanks a lot
Yunpeng Li

Really don't know what's to be done.
The heart beat messages are routed also to my inherited class of WireTcpHandler, i.e in the onRead() method.
So If I read using in.wire().read("heartbeat") to see if it's null, it bails out on my read "payload" messages.
If I read in.wire().read("payload") if bails on "heartbeat" messages.
A heartbeat message handler should be installed automatically???
Why should my code have to handle heartbeat messages also?
Am I doing something wrong?

Thanks,
TJ

See net.openhft.chronicle.network.ConnectionStrategy#pauseMillisBeforeReconnect and net.openhft.chronicle.network.AlwaysStartOnPrimaryConnectionStrategy#pauseMillisBeforeReconnect

I would appreciate a review from the original authors @RobAustin @peter-k-lawrey @dpisklov

See also https://github.com/ChronicleEnterprise/Chronicle-FIX/issues/299

When the developer knows the activity will be heavily read or write focused, this should be configurable.

If a host is unavailable and connection thread is interrupted, i.e. the JVM is being terminated, then AlwaysStartOnPrimaryConnectionStrategy starts an infinite loop of connection fails. Technically, it alternates between

What is the timeline/roadmap for UDP support?

Instead of 1 write/8 reads introduce possibility to make it 1 to 1

Maps are used extensively in TcpChannelHub.TcpSocketConsumer leading to a lot of Node, Long etc. creation.

Use Koloboke to reduce allocation.

When running DataGrid, the following messages appeared:

2020-04-21T15:04:35.107 main/replication-tcp-handler-2 UberHandler java.lang.NullPointerException
2020-04-21T15:04:35.107 main/replication-tcp-handler-2 UberHandler java.lang.NullPointerException
2020-04-21T15:04:35.107 main/replication-tcp-handler-2 UberHandler java.lang.NullPointerException

[Hundreds of similar lines not shown for brevity]

This provides little or no information pointing to the root cause of the problem.

Required for ChronicleEnterprise/Chronicle-FIX#33

Needed for ChronicleEnterprise/Chronicle-FIX#194

Please rename one of the following classes ( as we have two classes with the same name )

net.openhft.chronicle.network.ConnectionStrategy
net.openhft.chronicle.network.cluster.ConnectionStrategy

A client has ask that we change ConnectionStrategy to use System currentTimeMillis instead of tickTime()

I found a bug in this method exposed by occasional failure of FIX AcceptorInitiatorTest.testStartAndEndOfConnection()

Basically both the main thread and the event-loop-thread of the client FixEngine would attempt to call FixNetworkContext.close() and in fact enter the method simultaneously owing to lack of mutex. This would result in listener being notified twice and failing the test.

I think making the FixNetworkContext.close() method synchronised as in the base class is dangerous because it invokes listeners that could potentially do something to deadlock. And it would be better to avoid locks altogether.

My suggestion instead is to add a new VanillaNetworkContext.closeWithCAS() method to return boolean if state is actually changed (using AtomicBoolean member instead of volatile boolean).

added

Jvm.warn().on(getClass(), "port=" + ssc.socket().getLocalPort(), e);

@see should be replaced with @link at these locations:

[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/connection/FatalFailureConnectionStrategy.java:38: warning - invalid usage of tag >
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/BytesBufferHandler.java:18: warning - invalid usage of tag {@see NetworkContext}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/BytesBufferHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:18: warning - invalid usage of tag {@see TcpEventHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:23: warning - invalid usage of tag {@see SslEngineStateMachine}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}
[ERROR] /Users/pemi/git/chronicle/opensource/Chronicle-Network/src/main/java/net/openhft/chronicle/network/ssl/SslDelegatingTcpHandler.java:15: warning - invalid usage of tag {@see TcpHandler}

Allow the VanillaNetworkContext to be used for all network context so that a single port can serve a number of uses, in other words, remove the

QueueClusterNetworkContext
DatagridWireNetworkContext
MapClusterNetworkContext

and allow all the data to be stored and configured into the VanillaNetworkContext

Two of the three tests in WireTcpHandlerTest fail for me with the following exception on TextWire and BinaryWire. Cuirioulsy RawWire seems to pass without a problem.

I can workaround this by commenting out the heartbeats on WireTcpHandler.sendHeartBeat.

java.lang.UnsupportedOperationException: Unordered fields not supported yet. key=key1, was=heartbeat, data='heartbeat'
at net.openhft.chronicle.wire.TextWire.read(TextWire.java:260)
at net.openhft.performance.tests.network.TestData.lambda$read$5(TestData.java:46)
at net.openhft.performance.tests.network.TestData$$Lambda$13/742394451.readMarshallable(Unknown Source)
at net.openhft.chronicle.wire.Wires.lambda$readData$58(Wires.java:132)
at net.openhft.chronicle.wire.Wires$$Lambda$14/1916389359.accept(Unknown Source)
at net.openhft.chronicle.bytes.StreamingDataInput.lambda$readWithLength$1(StreamingDataInput.java:42)
at net.openhft.chronicle.bytes.StreamingDataInput$$Lambda$15/1063288177.apply(Unknown Source)
at net.openhft.chronicle.bytes.StreamingDataInput.parseWithLength(StreamingDataInput.java:54)
at net.openhft.chronicle.bytes.StreamingDataInput.readWithLength(StreamingDataInput.java:41)
at net.openhft.chronicle.wire.Wires.readData(Wires.java:132)
at net.openhft.chronicle.wire.WireIn.readDocument(WireIn.java:82)
at net.openhft.performance.tests.network.TestData.read(TestData.java:45)
at net.openhft.performance.tests.network.WireTcpHandlerTest.testLatency(WireTcpHandlerTest.java:113)
at net.openhft.performance.tests.network.WireTcpHandlerTest.testProcess(WireTcpHandlerTest.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
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.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
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.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:78)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:212)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)

When the client is closed it calls a listener which attempt to re-opne the connection.

[main/event-loop-monitor] INFO software.chronicle.runner.v2.Monitor -
at net.openhft.chronicle.wire.BinaryWire.write(BinaryWire.java:1031)
at net.openhft.chronicle.network.cluster.handlers.UberHandler.writeMarshallable(UberHandler.java:88)
at net.openhft.chronicle.wire.BinaryWire$FixedBinaryValueOut.marshallable(BinaryWire.java:1721)
at net.openhft.chronicle.wire.ValueOut.typedMarshallable(ValueOut.java:420)
at net.openhft.chronicle.network.cluster.handlers.UberHandler.lambda$uberHandler$5(UberHandler.java:64)
at net.openhft.chronicle.network.cluster.handlers.UberHandler$$Lambda$229/1711639613.writeMarshallable(Unknown Source)
at net.openhft.chronicle.network.connection.VanillaWireOutPublisher.put(VanillaWireOutPublisher.java:175)
at net.openhft.chronicle.network.connection.WireOutPublisher.publish(WireOutPublisher.java:114)
at net.openhft.chronicle.network.cluster.HostConnector.connect(HostConnector.java:118)
at net.openhft.chronicle.network.cluster.HostConnector.reconnect(HostConnector.java:130)
at net.openhft.chronicle.network.cluster.ClusterNotifier.onClose(ClusterNotifier.java:66)
at net.openhft.chronicle.network.cluster.ClusterNotifier.onConnectionChanged(ClusterNotifier.java:54)
at net.openhft.chronicle.network.cluster.handlers.UberHandler.close(UberHandler.java:189)
at net.openhft.chronicle.core.io.Closeable.closeQuietly(Closeable.java:42)
at net.openhft.chronicle.network.TcpEventHandler.closeSC(TcpEventHandler.java:367)
at net.openhft.chronicle.network.TcpEventHandler.close(TcpEventHandler.java:361)
at net.openhft.chronicle.core.io.Closeable.closeQuietly(Closeable.java:42)
at net.openhft.chronicle.threads.VanillaEventLoop.lambda$closeAll$0(VanillaEventLoop.java:118)
at net.openhft.chronicle.threads.VanillaEventLoop$$Lambda$390/972152147.accept(Unknown Source)
at java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:891)
at net.openhft.chronicle.threads.VanillaEventLoop.closeAll(VanillaEventLoop.java:116)
at net.openhft.chronicle.threads.VanillaEventLoop.closeAllHandlers(VanillaEventLoop.java:508)
at net.openhft.chronicle.threads.VanillaEventLoop.close(VanillaEventLoop.java:461)
at net.openhft.chronicle.core.io.Closeable.closeQuietly(Closeable.java:42)
at net.openhft.chronicle.core.io.Closeable$$Lambda$388/1091202270.accept(Unknown Source)

The following code might fail if the condition is true:

        if (resultType == CharSequence.class && usingValue != null)
            return f -> {
                f.textTo((StringBuilder) usingValue);
                return usingValue;
            };

If the resultType is equal CharSequence, then, by definition, it is not a StringBuilder even though the usingValue might be a StringBuilder