reconnection and thread safety

[manishpatelUK]

I've made changes to pom. which can be ignored.

Everything else:
A QConnection that can now reconnect if the database has been restarted since the last open() call.

A thread safe QConnection class.

I have used this in production for an API backed by KDB, and works very well. The next step is to create connection pools in my API so that I can have lots of KDB instances in a cloud service; this branch was just the background work.

[maciejlach]

Thank you for the pull request.

There are several points I would like to address:

• We decided to keep qJava compatible with JDK 5, thus avoiding for example: multi exception catch syntax.
• qJava library is not allowed to contain any print statements outside of samples folder.
• QBasicConnection is supposed to provided only basic connectivity without reconnection/synchronization.

It was a design decision not to include failover/reconnect logic into the basic library.
Actual failover/reconnect strategy should depend on your system architecture and can rely on:

• Reconnecting to the same host/port, either on a timer or upon a subsequent calls.
• Switching to another host/port from the connection pool.

One has to consider how the failover/reconnect logic should be applied in case of asynchronous subscription (i.e. QCallbackConnection class).

You can check out an alternative solution for basic synchronization and reconnection.

[manishpatelUK]

Hello

Thanks

We decided to keep qJava compatible with JDK 5

Fair enough. Makes following points moot, as I have a 1.8 requirement (eventually) but I'll address them anyway:

qJava library is not allowed to contain any print statements outside of samples folder

I didn't realise I had any aside from print stack traces... oversight.

QBasicConnection is supposed to provided only basic connectivity without reconnection/synchronization.

Sync is devolved to a subclass. Reconnect should have been too, so that's fair enough.

One has to consider how the failover/reconnect logic should be applied in case of asynchronous subscription (i.e. QCallbackConnection class).

Purposefully avoided that as this may well be used as a tickerplant feed, for which there may be multiple instances of the object.