Fork me on GitHub
#datomic
<
2019-06-27
>
enn15:06:23

Is it possible to override the path where the Datomic peer library looks for transactor-key.jks?

enn15:06:17

Sorry, I don't follow

enn15:06:16

In this case the data store is Dynamo ... so I don't think there is JDBC involved ... but I could definitely be mistaken

favila15:06:37

there's no datomic specific credentialing or jks

favila15:06:42

it's all storage-specific

favila15:06:31

I'm only aware of jdbc ssl needing client and/or server keystores

favila15:06:11

in the jdbc case it goes into the connection string

enn15:06:16

I believe this key is used for communication with the transactor, not the data store

favila15:06:52

did you make it? how did you come across it?

enn15:06:54

The last Datomic item in the stacktrace when it doesn't find the file is datomic.artemis-client/create-session-factory

enn15:06:26

I didn't make it. It's packaged with Datomic. I learned about it when I got an exception trying to start the peer library in an environment where the class path does not map to the filesystem in the way that the code seems to expect and it could not find the file.

favila15:06:15

I've been using datomic for 6 years and I've never come across this

favila15:06:25

the closest I can find is this sample code using hornet:

favila15:06:34

not datomic

favila15:06:55

im going to check a running app and see if it/s on the classpath

enn15:06:33

$ jar -tf datomic-pro-0.9.5661.jar | grep transactor-key
datomic/transactor-key.jks

favila15:06:05

I suspect you can't move it

favila15:06:22

changing it would mean providing a netty option

favila15:06:37

piercing through datomic->artemis->netty

favila15:06:38

how did this get messed up? uberjaring? strange repackaging?

favila15:06:06

it's always been a "just works" thing for me

enn15:06:08

This is on an AWS Lambda, which seems to put everything from the jar under /var/task

enn15:06:53

So this file lives at /var/task/datomic/transactor-key.jks but Artemis/Netty is still looking for /datomic/transactor-key.jks

favila15:06:50

but it should be a resource path not a literal path

enn15:06:41

Yes, but it looks like Artemis is bypassing the resource API

favila15:06:42

so if /var/task is on the classpath, it should find it

enn15:06:52

basing that on this part of the stacktrace I see:

Caused by: java.io.FileNotFoundException: /datomic/transactor-key.jks (No such file or directory) 
at java.io.FileInputStream.open0(Native Method) 
at java.io.FileInputStream.open(FileInputStream.java:195) 
at java.io.FileInputStream.<init>(FileInputStream.java:138) 
at java.io.FileInputStream.<init>(FileInputStream.java:93) 
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90) 
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188) 
at java.net.URL.openStream(URL.java:1045) 
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.loadKeystore(SSLSupport.java:104)

favila15:06:55

if that were true, wouldn't it never work?

favila15:06:05

transactor-key is always in a jar

enn15:06:10

Yes, that is something I've wondered

favila15:06:10

I mean, normally

enn16:06:17

Looking at code it does look like Artemis gets that URL by calling findResource ... so, yeah, I'm not sure what is going wrong on the lambda that that isn't working.

favila16:06:11

maybe artemis/netty version fighting?

favila16:06:38

datomic deps on an artimis "uberjar" which includes netty-all

favila16:06:53

actually that's imprecise

favila16:06:29

datomic deps on an older version of artemis which deps on netty-all, which includes every netty class

favila16:06:39

it's not a pure dependency pom

favila16:06:49

so getting two netty versions on the classpath was a common problem

favila16:06:59

perhaps that's what's happening?

enn16:06:11

Ah, interesting, I will look at the deps tree

favila16:06:27

This is what I kinda blindly do now:

favila16:06:30

[com.datomic/datomic-pro "0.9.5786"
                  :exclusions [org.slf4j/slf4j-nop org.slf4j/slf4j-log4j12
                               ;; netty-all is a netty "uberjar". When combined
                               ;; with other things that depend on netty sub-deps
                               ;; directly, we get duplicate netty classes of
                               ;; different versions on the classpath.

                               ;; In our case, artemis-client-core depends on
                               ;; netty-all 4.0; google-cloud-logging-logback
                               ;; transitively depends on specific netty packages
                               ;; (not netty-all); when combined, we get
                               ;; duplicate netty classes of different versions
                               ;; on the classpath.

                               ;; Solution: exclude netty-all and depend on what
                               ;; artemis *actually* requires. Then maven
                               ;; can resolve the dep tree correctly.
                               io.netty/netty-all]]

favila16:06:38

I got burned so hard

favila16:06:10

I have even considered repackaging datomic peer lib with a different pom that fixes this issue

favila16:06:14

elsewhere I will include this:

favila16:06:16

;; Source for artemis netty deps:
                 ;; 
                 ;; artemis-commons
                 [io.netty/netty-buffer "4.1.34.Final"]
                 [io.netty/netty-transport "4.1.34.Final"]
                 [io.netty/netty-handler "4.1.34.Final"]
                 ;; artemis-core-client
                 [io.netty/netty-transport-native-epoll "4.1.34.Final" :classifier "linux-x86_64"]
                 [io.netty/netty-codec-http "4.1.34.Final"]

enn16:06:50

I don't think I have anything else requiring netty

favila16:06:05

could lambda be doing it?

favila16:06:16

I guess this wouldn't fix the issue if it were

enn16:06:25

Looking more at that Artemis validateStoryURL function I am thinking that the DWIM nature of that might explain why it works someplaces and not others

enn16:06:33

it tries to handle URLs, file paths, and resource paths

favila16:06:01

I think it's ok to escalate to a datomic support ticket at this point

enn16:06:11

Yeah, I have, just trying to dig a little while I wait for their response

enn16:06:18

I wonder if this is what's happening:

enn16:06:24

in normal environments, file.exists() in validateStoreURL returns false so it falls through to the call to findResource, which finds it in the jar, and all is well

enn16:06:31

Lambda unzips the jar into /var/task which may also be the working directory of the process (not sure) so maybe that causes file.exists() to return true, so it returns the result of file.toURI().toURL() instead of calling findResource

enn16:06:15

I don't have an explanation for why, if that's true, the subsequent call to java.net.URL.openStream fails

favila17:06:59

me neither

okocim20:06:55

this may not be the right place to ask this question, but does anyone in here have a link to docs or refrence for using the cognitect http-client? I am trying to make use of this library since it’s already in my project, but I cannot for the life of me figure out how to send a request body on an http post. I am setting a :body key on the request that is a java.nio.ByteBuffer, and the API that I’m calling is complaining to me that my request doesn’t have a body. I’d like to avoid switching to another library if I can, but I am a bit nonplussed about how to use this library.

Alex Miller (Clojure team)20:06:27

I don’t think there are any docs, but the source is in the jar file

ghadi21:06:33

@okocim it's very very barebones

okocim15:06:01

Thanks for your help. You were right, my buffer positions were incorrect

ghadi21:06:13

make sure that when you hand in the ByteBuffer, the "read head" (.position) is not at the limit

Nolan21:06:41

How have others approached transitive dependency conflicts in datomic cloud? I’m using a library that depends on [email protected], while 1.10 (the datomic cloud dependency) causes a compilation error. I recognize it’s more of a JVM soft-spot than anything, I’m mainly curious how others have broached this in cases both where a the conflicting library can be forked and when it cannot.

ghadi21:06:24

is it a public library that needs 1.11 @nolan?

Nolan21:06:53

This instance is, yes. So in the worst case I could fork and maintain a version that works on 1.10. But I’m also curious about how I’d go about resolving the problem if that weren’t an option. It seems like that would be a difficult position to be in.

Nolan21:06:55

Is AOT relevant here? Is that a viable solution path? I’m not familiar enough with the JVM to know whether the conflict would still be experienced

Nolan21:06:24

I guess the package names would still conflict.

ghadi21:06:31

AOT isn't relevant

👍 4
ghadi21:06:53

(although if a library AOT's its code, that is not good)

ghadi21:06:13

generally a library might ask for latest (1.11) but not need the things from latest

ghadi21:06:25

which library, if I may ask?

ghadi21:06:49

In general, with Ions it has to prefer the Ion's version of a conflict, where there is a conflict

Nolan21:06:38

In this case (`clj-multiformats`) it’s a super trivial conflict—`clj-multiformats` uses encodeHexString with 2 arguments, which isn’t in the 1.10 API.

ghadi21:06:14

that's a "heh" of empathy 🙂

😂 4
👍 4
ghadi21:06:38

hex formatting is one thing that isn't in the Java stdlib directly... yet

ghadi21:06:50

(but anyways, Datomic Ions are Java 8)

ghadi21:06:05

we have base64 covered in the JVM now ....

ghadi21:06:23

a fork would probably be appropriate in that case

👍 4
ghadi21:06:33

which is really really trivial with git dependencies

ghadi21:06:47

nothing to compile. just fork, commit, change your dependency sha

ghadi21:06:04

(and nothing to mvn release, etc.)

Nolan21:06:31

Right on. Agreed. The whole thing is just a minor bummer, since its such a surface level incompatibility (I believe 1.11 even accretes appropriately)

Nolan21:06:21

I’d be curious if bumping commons-codec would ever make it onto the cloud roadmap. It appears that version bumps are something that releases occasionally cover, but commons-codec is also a pretty fundamental thing.

Nolan21:06:51

But thanks a million for your input @ghadi. Forking won’t be a huge hurdle here

ghadi21:06:05

np, cheers

🤝 4