Hopsworks singletons are not single

Description

Due to how we deploy Hopsworks (hopsworks-ear and hopsworks-ca separately) each class annotated as `@Singleton` will spawn actually 2 different ejbs. One as part of the hopsworks-ear application and one as part of the hopsworks-ca application.

First example: if we have a singleton timer bean, it will be started twice and will do the work twice.
Another example is the `OpenSSLOperations.java` which is supposed to synchronize on openssl operations as openssl doesn't really like concurrent operations. What happens though is that you can try to create a project (and generate the project certificate) and at the same time Hops can request a sign for an App CSR. These operations will be executed concurrently as they rely on 2 different singletons.

Right now hopsworks-common has basically all the business logic. Longer term we should look into reducing the scope of the package. For a shorter term solution, we should move all the security related classes in hopsworks-ca and make rest calls from hopsworks-ear each time we want to sign a certificate (for instance during project creation).
This strategy will help us moving to clustered hopsworks, where we have only a single glassfish instance signing the certificates, and all the other glassfish instances sending rest request to get stuff signed.

Assignee

Fabio Buso

Reporter

Fabio Buso

Labels

None

Fix versions

Affects versions

Priority

Highest
Configure