System.setProperty used by a thread impacts other thread in communication to external network elements. How to resolve it?

Question

In my application, I have two threads. Each thread communicates to different external entities.

Let us say T1 --> N1 & T2 --> N2 (T1 & T2 are two threads. N1 & N2 are external entities. Communications is SOAP over HTTPS.)

The vendor of N1 requested to use key store file UPCC_client.store for authentication and for the same we have used the following code,

System.setProperty("javax.net.ssl.keyStore", "<file path>");
System.setProperty("javax.net.ssl.keyStorePassword", "<password>");
System.setProperty("javax.net.ssl.trustStore","<file path>");
System.setProperty("javax.net.ssl.trustStorePassword", "<password>");

The application has been restarted with the above properties set in T1 thread with no issues. T2 started getting into trouble, since properties set by T1 are getting used by T2. The main reason behind this is System.setProperty is JVM scope. How to resolve this problem?

Answer 1

I suspect you have a design issue to have this requirement however.

The only way around this is I can think of is to make your properties ThreadLocal.

public class ThreadLocalProperties extends Properties {
    private final ThreadLocal<Properties> localProperties = new ThreadLocal<Properties>() {
        @Override
        protected Properties initialValue() {
            return new Properties();
        }
    };

    public ThreadLocalProperties(Properties properties) {
        super(properties);
    }

    @Override
    public String getProperty(String key) {
        String localValue = localProperties.get().getProperty(key);
        return localValue == null ? super.getProperty(key) : localValue;
    }

    @Override
    public Object setProperty(String key, String value) {
        return localProperties.get().setProperty(key, value);
    }
}

// Make the properties thread local from here. This to be done globally once.
System.setProperties(new ThreadLocalProperties(System.getProperties()));

// in each thread.
System.setProperty("javax.net.ssl.keyStore", "my-key-store");

---

Unless there is any confusion, System.setProperties() doesn't just set properties, it replaces the collection, and its implementation.

// From java.lang.System
 * The argument becomes the current set of system properties for use
 * by the {@link #getProperty(String)} method.

public static void setProperties(Properties props) {
    SecurityManager sm = getSecurityManager();
    if (sm != null) {
        sm.checkPropertiesAccess();
    }
    if (props == null) {
        props = new Properties();
        initProperties(props);
    }
    System.props = props;
}

By using this method the behaviour of System Properties changes to being thread local for calls to setProperty() and getProperty()

Answer 2

I arrived here looking for a solution to set system properties per thread. I used @Peter Lawrey's excellent example above and it was just what I needed with one exception - my code needed to be run inside a servlet container (Tomcat), and as such I was obligated to be a good citizen and not alter the expected behavior of setProperty() for any other webapp running within the same JVM instance. To address this, I renamed Peter's setProperty() method to setLocalProperty():

    public Object setThreadLocalProperty(String key, String value) {
        return localProperties.get().setProperty(key, value);
    }

With this one change, the result is that a call to setProperty() will alter the property globally - which will be the desired behavior for other threads within the JVM. To alter the property for just the local thread, the call is instead made to setThreadLocalProperty().

In summary if you have full control over your application instance then Peter's code should work great for you. If however your application lives in a shared JVM - or if you have a need to otherwise "layer" system properties into global and thread-local, the one modification above should work for you.

Answer 3

There are programmatic ways to set the keystore and truststore, see the JSSE Reference Guide, but why exactly do you think you need different keystores and truststores at all? The truststore is a list of every CA you trust: is that really different in different contexts: and the keystore is your identity: is that really different in different contexts? and if so why?

Answer 4

I tried above threadlocal example and creating seperate keystone to refer in two different thread. But at a time one connection create and other failed with error wrong truststore.