Dependency on Aleph and Netty causes issues deploying to wildfly and jboss #182
Comments
|
Can you upgrade the version of Netty that Wildly is using? |
|
Daniel,
No, I don't have control over that environment.
Creighton
…On Tue, Feb 7, 2017 at 2:31 PM, Daniel Compton ***@***.***> wrote:
Can you upgrade the version of Netty that Wildly is using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#182 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIlY_pMbS3_I5B4BHhZKUfJUu31KrBAks5raMaPgaJpZM4L52wv>
.
|
|
Can you share as much of your dependency tree as possible? It's a bit hard to debug further without more details on the Netty versions. Also, is it possible that there are two Netty JARs on the classpath under different artifact ID's (e.g. |
|
The issue come from Jboss and wildfly providing Netty and a specific version of netty. The only netty files are coming in from the rethinkdb.clj deps. The version of Widfly that I am trying to deploy to has 4.0.15-Final being provided. This normally wouldn't be an issue but aleph is highly coupled with specific versions of netty and rethinkdb is highly coupled with current release of aleph due to ssl support. Note: widlfly and jboss both use Netty as base module. deps tree root for rethinkdb: |
|
@danielcompton - Is there a reason you don't just wrap the java api? The RQL api seems like it matches your setup very closely. It feels like you could support almost everything you have with very little code around the official java api. |
|
The last time I looked, the Java driver didn't have any async support which means each changefeed would tie up a whole thread (I think). It's not uncommon to have thousands of changefeeds open, so this is a problem. I'd love to switch to using the Java driver, and it would make a lot of things a lot easier, but we need some sort of async support. Have you tried excluding io.netty/netty-all from the rethinkdb dependency? I don't have time to look into switching to the Java driver at the moment, or adding async support to the official Java driver, but if you wanted to provide a patch, I'd be happy to review it. Alternatively, if you're able to provide a patch to clj-rethinkdb which make the problematic netty code path optional, I'd be happy to remove that too. Are you trying to use SSL in your cluster? |
|
@danielcompton - thanks for the reply. That is a bummer. It would simplify so many things. I notice there is suggestion to use Netty. Probably should link this issue there also. I don't know how to reference this on that thread. rethinkdb/rethinkdb#4802 |
|
Totally agree, it's a bit of a bummer. Now that there's a bit more certainty around RethinkDB, people (including me) may be able to invest more time into the Java driver. If you can find a way to exclude the rethinkdb.ssl namespace unless it is needed, that could be a good option, but I'm not sure how (without doing dirty hacks). |
|
@danielcompton - I wrote a version of query that wraps the java driver to get around the issue. I did my best to make it a drop in replacement of query that way when async comes to the java api it can be added without issue. Do you think it would be good to open up a light version like this? |
|
Not quite sure what you mean by open up, but I'd be happy to see it as a PR, or as a separate project? |
The dependency on Netty and Aleph to manage the connection classpath collisions with Wildfly on some deployments. Wildfly uses an older version of netty that is not compatible with Aleph and will throw method not found exceptions.
The text was updated successfully, but these errors were encountered: