Logstash 6.2.1 and jdbc 4.3.3 Java::JavaSql::SQLException: No suitable driver found for jdbc:sybase:Tds:server:port #263
Labels
Comments
|
Absolutely the same problem with Redshift driver as well |
|
Same problem with FileMaker driver |
|
Hello, I had the similar issue with Logstash 6.2.2. I tried to connect to Redshift database using jdbc driver and got the same error as above. Logstash is trying to locate the driver library (i.e. redshift.jar file) in it's classpath - "/logstash-home-dir/logstash-core/lib/jars/". Hence when I copied my redshift.jar file to the classpath, it worked fine. Thanks, |
|
This may be related to the Java entry point, which should be a silent feature (e.g. no one should notice it). elastic/logstash#8161. It changed the way some of the resources are loaded starting with 6.2.0 |
|
@jakelandis hmm but the resource here is the SQL driver jar? That is loaded by the plugin code right? I don't think the changes made to loading the |
|
@jakelandis that said, we should still investigate this ... maybe the jar gem is loaded/configured in some different way now ... looking at #263 (comment) this is pretty likely. Missed that comment before posting above |
|
This is likely caused by elastic/logstash@dff953d#diff-ae70fbcbe615ab91d29724bf87b1c819 added in elastic/logstash#8161 in CC @jakelandis @jsvd |
|
@gmoskovicz but is the redshift jar nowhere to be found now (not even in the folder it was in before 6.2)? |
|
It seems to be the case. |
|
@original-brownbear so this really seems to be an issue within Logstash Core rather than this specific input, and it could be affecting more than this. Would you like me to open an issue in Logstash Core? Or given you understand the change/details you prefer to do that? |
|
I am trying my best to reproduce this , but coming up short. @daleckystepan @tovbin @Sp1n89 @sneha-dudhane19 @gmoskovicz - a couple questions:
|
I can also confirm that copying the jar to that lib folder makes it works. |
|
|
@original-brownbear - i think it is an issue with Java entry point, but not for the reasons originally thought. MySql and Postgresql work without issue, but Redshift fails when launched with the Java entry point, but works if re-introducing the Ruby entry point. I _think the difference is the JRuby TLS artifacts in use by the process when run via the Java entry entry point vs. the Ruby entry point. The diffs of the jars in use by the process i believe is the most telling. However, not sure how to proceed here. Could you take a look and the testing below to see what conclusions you draw ? Testing environment Logstash 6.2.3 / Fedora 24 In both cases I don't actually have the DB running, and am watching the error logged. It should load the driver, then complain about the connection, so the error should come from the driver. If the error comes from the driver, I consider it a success...if the error comes from unable to load type error, i consider it a failure (and inline with the OP's issue) I added this script to get the ruby entry point back for testing: Redshift:Works with Ruby entry point, Fails with Java endpoint. Config: Ruby entry point (works)Find the actual Jars for the process: Java entry point (doesn't work)Note - the error is not coming from the driver JAR, and assuming that the driver JAR can not load. Find the actual Jars for the process: Diff of Jars for running process:
Postgresql:Works with Ruby entry point and Java endpoint. Ruby entry point (works)Java entry point (works)Note - same error as Ruby entry point Find the actual Jars for the process: Difference : Looking at the class path from inside the Ruby pipelineAdd the following to Ruby entry pointpostgresql config Redshift config Java entry pointpostgresql config Redshift config Moving the driver to the class path
Java entry point for Redshift driver on the classpath (works)This does indeed fix it ..and the class path from inside ... and the diff to the java entry point when it is not on the classpath: Huh ?Still not sure what is actually happening... An educated guess is that the lack of the some the JRuby TLS artifacts (see diff screen shots) is the root cause. I presume that Redshift (and the others mentioned in this thread) rely on some of the TLS artifacts possibly in static scope and is failing to load. I also assume that when the driver is on the proper Java class path it can use the Java's runtime TLS stuff. I did try to add
|
|
@jakelandis I wasn't yet able to reproduce this, but I'm pretty convinced you found the issue here. I think you could simply revert ls core to the old behavior by loading jar dependencies and ruby maven in LS core, before plugins are loaded. You can do this by reverting this block (and only this block, not the |
|
@jakelandis I tried doing what I suggested above. It didn't work, unfortunately. Next thing I'd try would be to manually add |
|
@original-brownbear - tried adding lockfile for Logstash Same "No suitable driver found for ..." problem. |
|
It seems that we can fix this by explicitly adding the driver to the system class loader, instead of the JRuby runtime class loader. We currently load the jar with this directive: Which I think just does this : at least the behavior, and contents of that class loader identical. it seems to work. @original-brownbear - thoughts on this simple change ? |
|
@jakelandis first of all, 1000x thanks for figuring that out! :) I'm not so sure about the fix though. This wouldn't necessarily be BwC would it? |
|
@original-brownbear - I would have to test for BwC. I am not sure how we can keep the java entry point and make it behave the same as prior. A quick examination of the two class loaders against released versions: In runner.rb 6.2.05.6.7I should also note that it is surprising that we we reference the .m2 jars ...nothing to do with this issue, but it seems wrong since we ship the jars in the gems. |
|
@jakelandis I think the That said, I remember there was an option in JRuby to set the classloader. I guess it's worth looking into that? Will see what I can find out there. |
|
A quick looks like the change [1] it is backward compatible, which makes sense if the JRuby class loader is the child of the system loader. I agree that we should find a more common way via a core change if one exists, but i think this is viable alternative specific to the JDBC input plugin. [1] |
|
@jakelandis yea that makes sense with the child/parent relation => I'm +1 on fixing it this way for now :) |
jakelandis
added a commit
to jakelandis/logstash-input-jdbc
that referenced
this issue
Mar 26, 2018
…e JDBC drivers in Logstash 6.2+ Fixes logstash-plugins#263
|
Would love to get confirmation of the fix. |
jakelandis
added a commit
to jakelandis/logstash-filter-jdbc_streaming
that referenced
this issue
Mar 26, 2018
…e JDBC drivers in Logstash 6.2+ Related to: [JDBC input - #263](logstash-plugins/logstash-input-jdbc#263)
elasticsearch-bot
pushed a commit
to logstash-plugins/logstash-filter-jdbc_streaming
that referenced
this issue
Mar 29, 2018
…e JDBC drivers in Logstash 6.2+ Related to: [JDBC input - #263](logstash-plugins/logstash-input-jdbc#263) Fixes #10
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I'm experiencing issue with input jdbc plugin after upgrade to logstash 6.2.1 or 6.2.0 from 6.1.3. Same config, same setting, only different logstash package. If I downgrade the logstash everything works fine again.
Thank you for your help
/var/log/logstash/:
[ERROR][logstash.inputs.jdbc ] Unable to connect to database. Tried 1 times {:error_message=>"Java::JavaSql::SQLException: No suitable driver found for jdbc:sybase:Tds:server:port"}journalctl:
Nothing special, just start logstash.
The text was updated successfully, but these errors were encountered: