opcfoundation / ua-java-legacy Goto Github PK

Mainly applies to opc.tcp, i.e. PendingRequest subclass, but needs to be checked for https as well, written from the point of opc.tcp.

If PendingRequest.sendResponse is called with so large response that it is over the tcp transmit limits, then the AsyncWrite is set to error state with Bad_TcpMessageTooLarge. The message is never send back to the client meaning the client will timeout the request. I would assume this is not desired result. Instead the Bad_TcpMessageTooLarge should be returned to the client, or maybe if the returned message is too large only because it has too many nested diagnostics (which could happen if it is a result of e.g. StackOverflowException), it should drop out those until it can send the message.

Related to http://forum.prosysopc.com/forum/opc-ua-java-sdk/callback-when-server-is-initializedshutdown/

After doing some debugging and log interpretation, I have concluded that there must be a small window of opportunity where the OpcTcpServerConnection not yet have reached the Opening state before the socket receives a Hello message and the handshake procedure begins. The error we get is this one: https://github.com/OPCFoundation/UA-Java/blob/4a8c30579f58dd62133352d7637755b17e0f9e90/src/org/opcfoundation/ua/transport/tcp/nio/OpcTcpServerConnection.java#L287

which only could happen if the connection has not yet reached the Opening state. The OpcTcpServerConnection sets this state in its constructor, so somehow the socket must have started receiving data during construction. I suspect it is the input listener that is registered before the state is set (https://github.com/OPCFoundation/UA-Java/blob/4a8c30579f58dd62133352d7637755b17e0f9e90/src/org/opcfoundation/ua/transport/tcp/nio/OpcTcpServerConnection.java#L175-L177) that has started receiving input before setState has completed.

This is a conclusion drawn by reading the source code and logs only - I have not recompiled the stack with additional debug log statements to verify that this is in fact what is happening. More so, it appears to happen only on our Linux build server. Our windows and mac developer machines seems to not be affected, so it might also be related to some Java network stack behaviour.

Async tasks are handled in the stack blocking work executor. In case we do get multiple responses at the same time (one right after another from the tcp stream) we have 2 AsyncResult listeners active at the same time (since each result is handled in own thread). Because of thread scheduling, it is possible, that the response which arrived later gets to first call the listener. Therefore we might handle a PublishResponse which arrived later before the one which arrived earlier (and therefore do Republish and such).

In case there would be a option to have a singe threaded variant to this, which would handle these responses in order in which they arrive the above situation should not happen.

Steps to reproduce:
Send multiple PublishRequets using SessionChannel.PublishAsync. Use such settings that multiple responses are returned at the same time, e.g. max notifications 1 per response and have server generate enough data changes that we do receive at least 2 response at exactly same time (or well of course there is a small delay, since tcp is a binary stream, however they should arrive just after the other). Look at the sequence number in AsyncResult listeners of those requests. You probably need to repeat this several times. This was tested with one subscription, 500 monitored items, 1 data notification per response and data changing on the server every second. Every now and then the later response was the one received first from the listener.

The rule to stop certificate checks if a trusted certificate is found was removed since trusted CA certificates may be revoked by their issuers and therefore a full check of the certificate chain is required.

The certificate validation steps in Table 101 got reordered to first check Certificate Structure, Signature and Trust List. If one of the tree checks fails the unspecific status Bad_SecurityChecksFailed is returned. It the certificate is trusted, the remaining checks will return the specific error like defined in V1.02.

The first change should be already implemented since it reflects the certificate check test case matrix developed in the SMG.

But the changes in the Certificate Validation Step error handling (return of right error) must be applied to the stack.

Part 4 spec change see Mantis 2534
Compliance test update see Mantis 2496.

Hi,
I wonder which versions of Eclipse, Maven, etc are recommended for development ?
Thanks
Joerg

Hi,
I'm working on a OPC Publisher sample as contribution: https://github.com/mregen/UA-Java/commit/91f126dbdc1df8fa3450109849fea07434784abb
Now given the Maven build process my difficulty is a dependency on some external jar libs and I figured the place under examples may not be the best fit. Do you have advise where you would add such a sample and how to incorporate in the maven build process? My current thinking is to have a separate Maven build due to the dependencies (https://github.com/Azure/azure-iot-sdks/tree/master/javawrapper requires a manual build step to build the .jar for Azure IoT SDK integration).

Thanks,
Martin

With misbehaving server applications, ReadThread should handle Exceptions in more robust way.

Exception in thread “TcpConnection/Read” java.lang.IllegalArgumentException: Variant cannot be org.opcfoundation.ua.builtintypes.Variant
at org.opcfoundation.ua.builtintypes.Variant.(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getVariant(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getDataValue(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getDataValueArray(Unknown Source)
at org.opcfoundation.ua.core.EncodeableSerializer$121.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.AbstractSerializer.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.SerializerComposition.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getMessage(Unknown Source)
at org.opcfoundation.ua.transport.tcp.io.TcpConnection$ReadThread.run(Unknown Source)

Original forum post: http://forum.prosysopc.com/forum/opc-ua-java-sdk/tcpconnectionread-java-lang-illegalargumentexception/

We have a use case where we have many clients connecting to many different servers in the same JVM. To ease interpretation and correlation of threads and clients in diagnostics information, and to avoid "leaking" contextual information between threads shared by multiple clients, it would be nice to be able to configure thread pools individually for each client instance. This way we can tweak both concurrency and naming of thread groups for each client.

When mask==0 only NodeClass.Unspecified is returned. EnumSet.allOf(...) should be returned instead.

See #43 and #46. We need to support a development scenario that uses only the latest JDK.

Hopefully the combination of animal-sniffer-maven-plugin and source and target level of 1.6 for the maven-compiler-plugin should ensure that only Java 6 compliant code is used. Also at some point it needs to be checked if using Java 9 requires changes. In far future Java 10 wont be able to compile to target 1.6 (http://openjdk.java.net/jeps/182), but I suppose we can look at the situation when it is more relevant.

Fixing #47 should solve the problems for developing with JDK 8 and if we move the toolchains plugin definition to a 'release' or keep the 'jdk6' profile, but turn it by default off instead of current on by default.

If and when this change is done, it should be documented clearly.

The AccessLevel attribute has been extended in V1.03.

Current way of ant build.xml and having dependency libs in the repo directly is outdated concept. Given that all the dependencies are available from Maven Central, there should be no need to have dependencies on the repo itself. Also maven project and layout is the de facto standard (at least in open source projects) and recognized by many developers. It is also supported by all java IDEs.

The PrivKey can be stored in PEM format on the sdcard (ExternalStorage), but not in the internal storage. Reading it from there fails for some reason.

It would be safer to store the private key in the internal memory which only the application can access itself.

Title says it all. Also my eclipse complains about a missing build.properties file but that may be my own fault.

Additional rule for Variant decoding in UA Part 6:
"If ArrayDimensions are inconsistent with the ArrayLength then the decoder shall stop and raise a Bad_DecodingError"

StackUtils has Exectors, they are contained in public fields, but initialized lazily. The fields should be changed to private.

The stack should be able to provide callbacks to the application of various errors that occur in the communication.

This would enable reacting and recording the problems in a custom way, instead of just logging them.

Use the new UA Defined Types.xml etc to regenerate the code generated classes to support Spec. version 1.03

Add support for encoding and decoding unions as defined in Spec. 1.03 Part 6, 5.2.7 & 5.3.6

Each time the SampleClient is started it creates the certificate even if it is already present of the file system. As a consequence it is not possible to install the certificate on a remote server from the rejected certificates.

Steps to reproduce:
Proposed and tested fix for the getCert method. Use load insted of loadFromKeyStore.

Additional information:
public static KeyPair getCert(String applicationName)
throws ServiceResultException
{
File certFile = new File(applicationName + ".der");
File privKeyFile = new File(applicationName+ ".pem");
try {
Cert myServerCertificate = Cert.load( certFile );
PrivKey myServerPrivateKey = PrivKey.load( privKeyFile, PRIVKEY_PASSWORD );
return new KeyPair(myServerCertificate, myServerPrivateKey);
} catch (CertificateException e) {
throw new ServiceResultException( e );
} catch (IOException e) {
try {
String hostName = InetAddress.getLocalHost().getHostName();
String applicationUri = "urn:"+hostName+":"+applicationName;
KeyPair keys = CertificateUtils.createApplicationInstanceCertificate(applicationName, null, applicationUri, 3650, hostName);
keys.getCertificate().save(certFile);
keys.getPrivateKey().save(privKeyFile);
return keys;
} catch (Exception e1) {
throw new ServiceResultException( e1 );
}
} catch (NoSuchAlgorithmException e) {
throw new ServiceResultException( e );
} catch (InvalidKeyException e) {
// TODO Auto-generated catch block
throw new ServiceResultException( e );
} catch (InvalidKeySpecException e) {
// TODO Auto-generated catch block
throw new ServiceResultException( e );
} catch (NoSuchPaddingException e) {
// TODO Auto-generated catch block
throw new ServiceResultException( e );
} catch (InvalidAlgorithmParameterException e) {
// TODO Auto-generated catch block
throw new ServiceResultException( e );
} catch (IllegalBlockSizeException e) {
// TODO Auto-generated catch block
throw new ServiceResultException( e );
} catch (BadPaddingException e) {
// TODO Auto-generated catch block
throw new ServiceResultException( e );
} catch (InvalidParameterSpecException e) {
// TODO Auto-generated catch block
throw new ServiceResultException( e );
}
}

Under heavy load and a lot of failing connection attempts, especially, but also sometimes in normal operation, the server socket blocks so that no more connections are available from client applications.

The symptom is that the new connection attempts also stay in the CLOSE_WAIT state in 'netstat' listing.

The problem is reproducible in Linux operating systems and requires heavy load and failing connection attempts to reveal itself with a higher probability.

Since the socket gets blocked no more connections are available and this is a severe issue for the applications.

--> related to Mantis 3117

org.opcfoundation.ua.common.ServiceResultException: Bad_CommunicationError (code=0x80050000, description="2147811328, peer not authenticated")
at org.opcfoundation.ua.transport.https.HttpsClientPendingRequest.run(HttpsClientPendingRequest.java:176)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:397)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:827)
at org.opcfoundation.ua.transport.https.HttpsClientPendingRequest.run(HttpsClientPendingRequest.java:130)
... 3 more

NOTE:
Looks like there is a problem with the CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256, which does not work with the Java SSL classes for some reason. If we include TLS_RSA_WITH_AES_128_CBC_SHA or TLS_RSA_WITH_AES_256_CBC_SHA as an optional Cipher Suite, it works fine. I would recommend at this point, adding these as allowed TLS1.2 ciphers to the Profile specification.

http://bouncy-castle.1462172.n4.nabble.com/Problems-with-OAEP-SHA-256-hash-crypto-td1466852.html [^]

Using basic 256 (rsa oaep), encrypting data with SunJCE provider and decrypting the encrypted data with
Bouncy Castle lightweight crypto API (non-jce provider) produces the following exception:

org.opcfoundation.ua.common.ServiceResultException: Bad_InternalError (code=0x80020000, description="2147614720, data hash wrong")
at org.opcfoundation.ua.transport.security.BcCryptoProvider.decryptAsymm(BcCryptoProvider.java:184)
at org.opcfoundation.ua.transport.security.BcCryptoProvider.decryptAsymm(BcCryptoProvider.java:154)
at org.opcfoundation.ua.unittests.TestCrypto.encryptDecryptAsymm(TestCrypto.java:73)
at org.opcfoundation.ua.unittests.TestCrypto.testEncryptDecryptRsaOaep(TestCrypto.java:43)
...
Caused by: org.bouncycastle.crypto.InvalidCipherTextException: data hash wrong
at org.bouncycastle.crypto.encodings.OAEPEncoding.decodeBlock(Unknown Source)
at org.bouncycastle.crypto.encodings.OAEPEncoding.processBlock(Unknown Source)
at org.opcfoundation.ua.transport.security.BcCryptoProvider.decryptAsymm(BcCryptoProvider.java:177)
... 22 more

This is hard coded, to make the XML serialiser to work with the standard types. However, it breaks interoperability since the references are now referring to the nodes with NamespaceUri, especially for the standard nodes. But for those it is least necessary to define the Uri since that is a constant value.

This was changed in the latest stack.

Current line is
throw new ParseException("Cannot parse DateTime from " + s + " expecting format 'yyyy-MM-dd'T'mm:hh:ssZ', for example '2011-04-13T11:47:12Z' for UTC timezone", 0);

it should be
throw new ParseException("Cannot parse DateTime from " + s + " expecting format 'yyyy-MM-dd'T'hh:mm:ssZ', for example '2011-04-13T11:47:12Z' for UTC timezone", 0);

i.e. the 'hh' and 'mm' parts should be changed

It loops all requests, which are currently sent or unsent. It does stop on first unsent request, but assuming we do have lots of requests that are sent, but not returned, we might end up looping quite a lot. The backing implementation is ConcurrentHashMap so there is no ordering.

I suggest one map for all sent but not yet returned requests and move unsent requests to a queue. Just before sending the message, add it to the sent requests map (so that we can be sure that it exists in the sent requets map before we do send in case it returns fast).

If Decoding exceptions occur on the client side, they will make the secure channel closed and leads eventually to a timeout, because the error is not returned properly to the client.

The problem can be revealed with large strings, which overcome the MaxStringLength limit (64K by default).

A sample log:
03/21/2013 16:28:30.647 ERROR [TcpConnection/Read] org.opcfoundation.ua.transport.tcp.io.TcpConnection ? - localhost/127.0.0.1:6006 Error
org.opcfoundation.ua.encoding.DecodingException: Bad_EncodingLimitsExceeded (code=0x80080000, description="MaxStringLength 65535 < 227846")
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.assertStringLength(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getString(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getXmlElement(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getScalarObject(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getVariant(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getDataValue(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getDataValueArray(Unknown Source)
at org.opcfoundation.ua.core.EncodeableSerializer$113.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.AbstractSerializer.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.utils.SerializerComposition.getEncodeable(Unknown Source)
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getMessage(Unknown Source)
at org.opcfoundation.ua.transport.tcp.io.TcpConnection$ReadThread.run(Unknown Source)
03/21/2013 16:28:30.654 ERROR [TcpConnection/Read] org.opcfoundation.ua.transport.tcp.io.TcpConnection ? - localhost/127.0.0.1:6006 Error
org.opcfoundation.ua.common.ServiceResultException: Bad_SecureChannelIdInvalid (code=0x80220000, description="Bad_SecureChannelIdInvalid (code=0x80220000, description="The specified secure channel is not longer valid.")")
at org.opcfoundation.ua.transport.tcp.io.TcpConnection$ReadThread.run(Unknown Source)
03/21/2013 16:28:31.660 ERROR [TcpConnection/Read] org.opcfoundation.ua.transport.tcp.io.TcpConnection ? - localhost/127.0.0.1:6006 Error
org.opcfoundation.ua.common.ServiceResultException: Bad_SecureChannelIdInvalid (code=0x80220000, description="Bad_SecureChannelIdInvalid (code=0x80220000, description="The specified secure channel is not longer valid.")")
at org.opcfoundation.ua.transport.tcp.io.TcpConnection$ReadThread.run(Unknown Source)

The checks for array length in BinaryDecoder may overflow:

if (len*2>remaining()) throw new DecodingException(StatusCodes.Bad_EndOfStream, "Buffer underflow");

This is a possible overflow issue. Since len is an int, if it is more than Integer.MAX_VALUE / 2, it will overflow in the comparison and will turn negative and always be false. This can be prevented by casting len to a long first:​

if ((long)len*2>remaining()) throw new DecodingException(StatusCodes.Bad_EndOfStream, "Buffer underflow");

This should be fixed in all getXxxArray methods.

In case the endpoints are bound to some addresses only, it should be ensured that they are only returned for the endpoint requests coming from that interface.

The Java stack is capable of handling several certificates, but it seems to return several endpoints for the same security settings for each certificate, especially for SecurityMode.None, which has no limits for the certificate key size (other policies define the valid keysize range).

Also, if no user token policies, except for the Anonymous would be defined, the server certificate is defined for the endpoints - although that was not supposed to be the case.

In practice, this can lead to user password decryption failure, if the client cannot use a big certificate that may be returned fro the endpoint, to be used for password encryption.

Currently stack threads are using names like Blocking-Work-Executor-X. It would be better to use names that point them to the stack. Especially when some automatic tools will monitor application and will spot some problems with them.

For example, the threads could be named Opcua-Stack-Executor-X.

There is StackUtils.shutdown which should stop the worker thread pools. Still is some cases it seems it is not enough and some thread is left running.

One of the reasons can be that the RejectionHandler for BLOCKING_WORK_EXECUTOR is made

            ((ThreadPoolExecutor) BLOCKING_EXECUTOR).setRejectedExecutionHandler( new RejectedExecutionHandler() {
                @Override
                public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
                    // Fail-safe, should not occur (unless in shutdown)
                    Executors.newSingleThreadExecutor().execute(r);
                }});

Thing is that indeed during shutdown all requests to the executor goes to the rejection handler. And if the rejection handler does create a new executor for it, that executor is not shut down, therefore we do have a live non-daemon thread running and the application wont stop.

Currently there is no way to detect if a server supports writing of status and or timestamp.

One option would be to have a server wide capability information about general support of this feature.

A more specific information would be to extend the access level with additional flags for StatusWrite and TimestampWrite.

Javadocs should be fixed so that they wont stop building on JDK 8.

The Java stack client is sending its CloseSecureChannelRequest as an UA Secure Conversation Message, instead of a CloseSecureChannel message within a CloseSecureChannelRequest.

It sends the body of the CloseSecureChannelRequest inside a message
with a MSGF header instead of a CLOF header.

Firewall maps traffic from port number 48401 to internal network port 4840 (opc.tcp). Connecting to server does not work. This leads to EndpointBinding in OpcTcpServerConnection being null causing NPEs.

Import the standard engineering units as defined in Spec. 1.03 Part 8 into a helper class, such as EngineeringUnits. The class could be code generated using the CSV file available from

https://opcfoundation.org/UA/EngineeringUnits/UNECE/UNECE_to_OPCUA.csv

This will define a list of EUInformation objects - that should be in a map that enables searching for the object using the UnitId - and possibly the DisplayName and Symbol as well.

The private key is stored as base64 encoded, but in one line. Openssl defines a mx 80 characters per line for it and therefore the keys are not readable with it.

Note:
This applies to keys stored without a password. With password it is stored differently - and requires Bouncy Castle.

I ran into a few build issues with maven cmd line build on windows:

it only succeeded after disabling test and javadoc

mvn package -DskipTests=true -Dmaven.javadoc.skip=true

Please repair.

This test should pass, but does not.

ExpandedNodeId nullUri = new ExpandedNodeId(NamespaceTable.OPCUA_NAMESPACE, UnsignedInteger.valueOf(0));
Assert.assertTrue(nullUri.isNullNodeId());

The reason is that the isNullNodeId implementation checks equals to ExpandedNodeId.NULL which is formed using the index (via NodeId.NULL_NUMERIC). Need to add checks for URI based null too.

It is not clear which values and combination of values are allowed for the elements in the dimensions array of matrices.

Suggestion for valid configurations:
[-1;-1;-1] for null matrix (according to array with length -1)
[0;0;0] for emtpy matrix (according to array with length 0)
[n>0;n>0;n>0] for all remaining configurations

Values < -1 should not be allowed.
0 or -1 in combination with values > 0 should not be allowed. (i.e. [-1;1;1])

Current stacks seem to preserve the input values which creates difficulties for the applications.

Stack should not try to "correct" invalid values but reject them.
The compliance test tool should provide tests with valid and invalid values.

--> related to Mantis 2819

The ANSI C and .NET stacks include code to validate certificates. This is a fundamental feature that should be part of the stack.

The feature should be implemented using the Java CertPath architecture
http://download.java.net/jdk8/docs/technotes/guides/security/certpath/CertPathProgGuide.html [^]

Add support for encoding and decoding optional structure fields as defined in Spec. 1.03 Part 6, 5.2.6 & 5.3.5

It seems that the Apache Http libraries (http://hc.apache.org/index.html [^]) that were used for the HTTPS implementation are indeed included in Android by default, but they are of an older version and do not provide all features used by the current HTTPS implementation.

However, the latest versions are also available, but repackaged, similar to Spongy Castle vs. Bouncy Castle. They are available from

http://code.google.com/p/httpclientandroidlib/ [^]

(the client lib)

This will require a copy of the implementation linked to these classes instead of the standard HttpClient classes, to make it work on Android.

Since Unspecified is not defined in the specification, we should also remove this identifier from the stack. 'null' value should be used instead to define an undefined NodeClass - for consistency with other enumerations in the stack.

However, it can be a breaking change, if applications have been using it to detect an undefined, so further consideration should be given.

Since the SunJceCertificateProviderhas to use private api to create the certificate (and therefore can break between JRE versions), it should be better in my opinion to disable the fallback to the provider (which happens if BC/SC providers are not present) by default. To enable it either a switch in CryptoUtil should be made or require the provider to be manually set via CryptoUtil.setCryptoProvider.

On longer schedule it could maybe be moved to a different module or something so we could change the animal-sniffer-maven-plugin to only check for java16 signature instead of java16-sun.

Currently EncoderUtils has 2 put methods:

put(IEncoder encoder, String fieldName, Object o)
put(IEncoder encoder, String fieldName, Object o, Class<?> clazz)

The one with Class parameter delegates to the one without it if the Object to be serialized is not null. That method uses the object.getClass to determine which serializer to use.

This should be changed so that put(IEncoder encoder, String fieldName, Object o) delegates to put(IEncoder encoder, String fieldName, Object o, Class<?> clazz) with class parameter o.getClass or throws EncodingException (or some other?) if the given object is null (currently it would give NPE because o.getClass is checked without null check first).

The reason is that if we have a Structure A that has Field1 that has datatype Structure B and we have assigned to that field a Structure C which extends B, we should serialize the Field1 as it were Structure B, because the binary stream does not have identifiers for fields which have structure values, their fields are serialized in order to the stream (see example in spec Part 6, section 5.2.5), so receivers of that stream would have no information that it should try to deserialize C instead of B.

The current implementation selects the first message it does encounter. The current logic is:

1. Take long next=Long.MAX_VALUE
2. Loop all requests (this would be also a performance issue if not this bug)
3. If request.timeoutTime is smaller than next (1.) set it to result and break the loop.

This means we always do get the first request (since in most cases the timeout time is always smaller than the max value of long, unless the message has no timeout, then it is the max value, but most of the request do have timeout). Also looping all the values is not good for performance. We probably could use something like java.util.concurrent.DelayQueue.

The stack is currently using Apache HTTP Core libraries that are 2 years old (v4.2.4/5). These should be updated to the latest (v4.4.1). The stack cannot currently be used with the latest versions, so there are some interface changes that need to be handled for that.

There are reported several performance optimizations, so this should help wit hthose issues a s well.

Details about changes:

http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES-4.4.x.txt [^]
http://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.4.x.txt [^]

Seems weird that there is a class SnapshotArray when JDK CopyOnWriteArrayList should do the same work.