9:01 a.m.
Are you interested in allowing NoSQL databases access from WildFly
application deployments? This email is about an integration effort to
allow WildFly applications to use NoSQL. Feedback is welcome on this
effort, as well as help in improving [1]. Some basic unit tests are
already added that show a session bean reading/writing MongoDB [2] +
Cassandra [3] databases. In order for the tests to pass, the local
machine must already be running MongoDB or Cassandra databases.
1. Things that currently (seems to be) working in the prototype:
* During WildFly startup, MongoDB/Cassandra databases are connected to
based on settings in their respective subsystems. See the configuration
example [4].
* Applications can access native MongoDB/Cassandra objects that
represent database connections (with internal native connection
pooling). See @Resource example [2][3]. Will see how the requirements
evolve going forward and whether @Resource is the right way and/or
whether other annotations are needed.
2. Currently not working in the prototype:
* Multiple hosts/ports cannot be specified yet for target database.
* Protection against applications closing pooled connections.
* NoSQL drivers currently may create threads in EE application threads
which could leak ClassLoaders/AccessControlContexts. One solution might
be to contribute a patch that allows WildFly to do the thread creation
in some fashion for the NoSQL drivers.
* We have not (yet) tried using (Java) security manager support with the
NoSQL driver clients.
* Additional NoSQL connection attributes need to be added to the NoSQL
subsystems.
* Native NoSQL class objects are bound to JNDI currently (e.g.
MongoClient). We might want to bind wrapper or proxy objects so that we
can extend the NoSQL classes or in some cases, prevent certain actions
(e.g. prevent calls to MongoClient.close()). Perhaps we will end up
with a mixed approach, where we could extend the NoSQL driver if that is
the only way to manage it, or contribute a listener patch for WildFly to
get control during certain events (e.g. for ignoring close of pooled
database connections).
* The prototype currently gives all (WildFly) deployments access to the
Cassandra/MongoDB driver module classloaders. This is likely to change
but not yet sure to what.
3. The Weld (CDI) project is also looking at NoSQL enhancements, as is
the Narayana project. There is also the Hibernate OGM project that is
pushing on JPA integration and will also help contribute changes to the
NoSQL drivers that are needed for WildFly integration (e.g. introduce
alternative way for NoSQL drivers manage thread creation for background
task execution).
4. We will need a place to track issues for NoSQL integration. If the
NoSQL integration changes are merged directly into WildFly, perhaps we
could have a nosql category under https://issues.jboss.org/browse/WFLY.
5. You can view outstanding issues in the MongoDB server [5], Java
driver [6] to get feel for problems that others have run into (just like
you would with WildFly). You can view outstanding issues in the
Cassandra server [7] and Java driver [8] to get a feel for problems as well.
6. Infinispan [9] integration in WildFly is still going strong.
Infinispan is still the backbone of WildFly clustering and also
available for applications to use as a datasource.
7. The standalone.xml settings [4] will soon change (would like to
eliminate the "name=default", add more attributes and get the multiple
host/ports wired in).
8. If the NoSQL unit tests do stay in the WildFly repo, they will need
to be disabled by default, as most WildFly developers will not have a
NoSQL database running. Speaking of which, we need to wire the unit
tests to update the standalone.xml to contain the MongoDB/Cassandra
subsystem settings [4].
9. What version of NoSQL databases will work with the WildFly NoSQL
integration? At this point, we will only work with one version of each
NoSQL database that is integrated with. Because we are likely to need
some changes in the NoSQL client drivers, we will work with the upstream
communities to ensure the NoSQL driver code can run in an EE container
thread, without causing leaks. First we have to identity the changes
that we need (e.g. find some actual leaks that I only suspect will
happen at this point and propose some changes). The Hibernate OGM team
is going to help with the driver patches (thanks Hibernate OGM team! :-)
10. Going forward, how can WildFly extend the NoSQL (client driver
side) capabilities to improve the different application life cycles
through development, test, production?
Scott
[1] https://github.com/scottmarlow/wildfly/tree/nosql-dev
[2]
https://github.com/scottmarlow/wildfly/blob/nosql-dev/testsuite/compat/sr...
[3]
https://github.com/scottmarlow/wildfly/blob/nosql-dev/testsuite/compat/sr...
[4] https://gist.github.com/scottmarlow/b8196bdc56431bb171c8
[5] https://jira.mongodb.org/browse/SERVER
[6] https://jira.mongodb.org/browse/JAVA
[7] https://issues.apache.org/jira/browse/CASSANDRA
[8] https://datastax-oss.atlassian.net/browse/JAVA
[9] http://infinispan.org