This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-02
Channels
- # announcements (9)
- # asami (5)
- # babashka (16)
- # beginners (134)
- # chlorine-clover (3)
- # cider (15)
- # clojure (75)
- # clojure-australia (3)
- # clojure-europe (29)
- # clojure-nl (2)
- # clojure-uk (15)
- # clojured (4)
- # clojurescript (34)
- # cursive (9)
- # datomic (16)
- # duct (7)
- # events (4)
- # fulcro (2)
- # helix (5)
- # honeysql (4)
- # jobs (9)
- # lsp (55)
- # malli (31)
- # music (3)
- # re-frame (3)
- # reitit (1)
- # remote-jobs (1)
- # ring (3)
- # sci (5)
- # shadow-cljs (46)
- # specter (3)
- # tools-deps (60)
- # vim (5)
- # xtdb (15)
This Kotlin shim may be of interest: https://twitter.com/juxtpro/status/1410945489307062276
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"}
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
it indeed seems pedestal uses a different version https://clojars.org/io.pedestal/pedestal.jetty
FWIW this has actually been fixed in io.pedestal/jetty
https://github.com/pedestal/pedestal/blob/d20065013abf5d3793ae5301e18a2398707fa2a9/jetty/src/io/pedestal/http/jetty.clj#L186
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 🙂
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!
@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 🙂
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?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
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?
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 😉
I am hoping crux needs one table for tx and one for docs and I am for now using in-memory indexing
> 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
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