I want to implement as much concurrency as possible. therefore it seems best to run 1 jforex-api per instrument.

However if i am trading a lot of instruments this means i have a lot of connections/subscribes to the dukascopy servers etc. is this against policy or is this not a problem at all ?

This is not a good idea. Consider starting with a single-threaded strategy which uses multiple instruments. And only then if the instrument count really affects the performance then consider using multiple threads. If you could describe more in particular what you are trying to do and what problems you encounter, we could give you some more specific advice on how to go about solving them.

Hi API Support,

The reason for this question is because i am running my own proprietary trading system. I am bridging the Dukascopy api to this system.

My trading system uses 1 process per tcp-connection, to make full use of all the CPU's in the system and to minimize delay i need to send different quotes over the different connections.

This is not a problem in Java and i build it already. However the current implementation sends a quote over the connection, then waits for feedback (get order details to place order, or just continue). and then sends another quote.

Because all the different quotes are handled after each other (serial) i cannot improve performance. And this increases delay.

I did try running multiple strategy's and filter out the quotes (strategy 1 processes EUR/USD and discards other instruments, strategy 2 processes USD/JPY etcetc). however this increases load/delay in java because every strategy is subscribed to all the instruments and processes/filters them.

Have you measured how much of delay it actually does cause?
Consider having a thread per-connection/quote. Waiting feedback can be used by using Future, see: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html