Fork me on GitHub
#xtdb
<
2021-07-02
>
richiardiandrea19:07:16

Hi there, has anybody ever seen this in the logs?

Execution error (NoSuchFieldException) at java.lang.Class/getField (Class.java:1703).
checkProtocolNegotiationAvailable
Not even sure where it comes from but I have just added the following to my deps.edn
pro.juxt.crux/crux-core             {:mvn/version "1.17.1"}
        pro.juxt.crux/crux-http-server      {:mvn/version "1.17.1"}
        pro.juxt.crux/crux-jdbc             {:mvn/version "1.17.1"}

richiardiandrea19:07:29

removing pro.juxt.crux/crux-http-server solves that - I am using io.pedestal/pedestal.jetty so there might be some dep shenanigans going on there

richiardiandrea20:07:01

it indeed seems pedestal uses a different version https://clojars.org/io.pedestal/pedestal.jetty

refset22:07:13

Hi @U0C8489U6 I've not seen it so far, but thanks for flagging and digging in - I just added a note to the project board, so we'll take a look next week 🙂

❤️ 3
jarohen09:07:02

Hey @U0C8489U6 - we've looked at the versions of Jetty between Crux and Pedestal - seems we use 9.4.36 and Pedestal (0.5.9) uses 9.4.35. I can't see any related changes in this version - could you confirm which Pedestal version you were using, and whether you can repro the issue with this latest version? cheers!

richiardiandrea15:07:29

@U050V1N74 no problem any time if I can help It turns out Pedestal 0.5.3 was using a function call that was deprecated in recent Jetty - the call was commented out in recent (3 years ago!) pedestal versions: https://github.com/pedestal/pedestal/blob/master/jetty/src/io/pedestal/http/jetty.clj#L185-L186 https://github.com/pedestal/pedestal/commit/bd9f32deaaed232fbea0af31a2666ef82559a8ca For some reasons we had never bumped neither pedestal nor Jetty until my Crux spike 🙂

richiardiandrea22:07:21

Other observation. I am trying to pass an already open :db-spec to the configuration - I have an existing HikariDataStore ready for use. However when I do that, I receive:

2021-07-02 16:10:54,626 ERROR                            com.zaxxer.hikari.pool.HikariPool - HikariPool-3 - Exception during pool initialization.
org.postgresql.util.PSQLException: The server requested password-based authentication, but no password was provided.
	at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:493)
	at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:205)
	at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
	at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:195)
	at org.postgresql.Driver.makeConnection(Driver.java:452)
	at org.postgresql.Driver.connect(Driver.java:254)
	at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:121)
	at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:358)
	at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:206)
	at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:477)
	at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:560)
	at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:115)
	...
Is that a supported use case?

richiardiandrea22:07:31

I checked the code and it won't work with the current implementation of ->connection-pool I see there would be a way though, I'd need a new custom Crux module

👍 3
refset08:07:46

Thank you for this report also(!) I hope you're not too blocked. What is the scenario here though? You're hoping to use the same database for regular SQL stuff alongside Crux using it as a tx-log / doc-store backend?

richiardiandrea16:07:13

Thanks @U899JBRPF! yes we are basically going to want to use Postgres for both Crux and other tables we have, slowly migrating to Crux if my spike goes well 😉

🤞 2
richiardiandrea16:07:58

I am hoping crux needs one table for tx and one for docs and I am for now using in-memory indexing

refset18:07:48

> we are basically going to want to use Postgres for both Crux and other tables we have Ah okay, and would you expect it all to share the same schema also? > I see there would be a way though, I'd need a new custom Crux module I'd be curious to understand what you think needs to change here. Feel free to open an issue, if only to help others figure it out faster...unfortunately I can't promise we'll be able to prioritise a fix soon. > I am hoping crux needs one table for tx and one for docs My understanding is that both will live in one tx_events table by default, but I think you could specify different schemas here also to keep them separated

richiardiandrea19:07:32

for now I was thinking of keeping it in the same schema but maybe a separate one is a good idea > I'd be curious to understand what you think needs to change here. Feel free to open an issue, if only to help others figure it out faster...unfortunately I can't promise we'll be able to prioritise a fix soon. I can dig into the code - it might be good to have a function similar to ->connection-pool but there in case you already have a pool already. There might also just be a bug lurking here so I am not 100% sure of the fix

👌 2