Fork me on GitHub
#datomic
<
2016-07-04
>
casperc13:07:38

@isaac: No, it doesn't

isaac13:07:24

@casperc: I got it, thanks

zentrope18:07:55

Is there a reason upgrading to 5385 would give me a “Transactor request timed out” even after destroying and re-creating the database, etc, etc?

zentrope18:07:21

Seems to get hung up on create-database.

zentrope18:07:18

Why would (d/create-database “datomic:) fail with a timeout? Strange!

zentrope18:07:03

Hm. Downgrading to client 5372 talking to server 5385 works.

zentrope18:07:01

Does 5385 somehow break something running on OpenJDK 8?

zentrope18:07:25

Hm. Not sure where to report this. Mailing list? Huh.

bvulpes18:07:12

zentrope: is your transactor also 58385?

bvulpes18:07:37

ah, i see it now.

bvulpes18:07:59

so 5385->5385 doesn't work but 5372 -> 5385 does?

zentrope18:07:38

I see this in the logs org.hornetq.core.server - HQ222190: Disallowing use of vulnerable protocol: SSLv2Hello. See for more details. but it’s just a WARN.

zentrope18:07:49

But that’s not every time. Kinda one of those “note it once” things.

zentrope18:07:14

Also: {:event :transactor/admin-command, :cmd :create-database, :arg {:db-name “my_db"}, :result {:exists “my_db"}, :pid 83706, :tid 125}

zentrope18:07:43

{:event :transactor/remote-ips, :ips #{"127.0.0.1"}, :pid 83706, :tid 63}

zentrope19:07:50

2016-07-04 12:12:45 | DEBUG | org.hornetq.core.client   | ClientSessionFactoryImpl received backup update for live/backup pair = TransportConfiguration(name=4a096a42-421b-11e6-b265-a7082dd004e2, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?trust-store-path=datomic/transactor-trust-jks&trust-store-password=transactor&port=4334&ssl-enabled=false&key-store-path=datomic/transactor-key-jks&key-store-password=****&host=127-0-0-1 / null but it didn't belong to TransportConfiguration(name=4a096a42-421b-11e6-b265-a7082dd004e2, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?trust-store-path=datomic/transactor-trust-jks&trust-store-password=transactor&port=4334&ssl-enabled=false&key-store-path=datomic/transactor-key-jks&key-store-password=****&host=127-0-0-1
2016-07-04 12:12:45 | ERROR | org.hornetq.core.client   | HQ214000: Failed to call onMessage
java.io.EOFException: null
	at org.fressian.impl.RawInput.readRawByte(RawInput.java:40)
	at org.fressian.FressianReader.readNextCode(FressianReader.java:927)
	at org.fressian.FressianReader.readObject(FressianReader.java:274)
	at datomic.hornet$create_deserializer$fn__6605.invoke(hornet.clj:353)
	at datomic.hornet$create_rpc_client$fn__6638.invoke(hornet.clj:412)
	at datomic.hornet$set_handler$reify__6592.onMessage(hornet.clj:288)
	at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1116)
	at org.hornetq.core.client.impl.ClientConsumerImpl.access$500(ClientConsumerImpl.java:56)
	at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1251)
	at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:104)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

zentrope19:07:18

Something in my client app is messing things up. I can run an inlein script and connect just fine.

zentrope19:07:22

Ah hah. If I have a dependency on aleph, the latest datomic client breaks.

zentrope19:07:30

aleph -> [io.netty/netty-all "4.1.0.CR3”] , datomic -> [io.netty/netty-all "4.0.13.Final"]

zentrope19:07:59

and “lein deps :tree” didn’t find that as an issue.

zentrope19:07:50

What do you do when you have incompatible dependencies like this? If I exclude from datomic, it’s broken. If from aleph, aleph is broken.

alexmiller19:07:26

this is the problem colloquially known as “jar hell”. The “tree” of dependencies is flattened into a linear classpath (often with little control from a user standpoint) where the jar version being used is whichever happens to come “first”, rather than the one that is actually needed by a particular dependency. This is one of the primary motivations for the classpath module system being added in Java 9.

alexmiller19:07:11

Usually you first try to exclude unneeded deps

alexmiller19:07:21

Then try to find a version that is harmonious with both

alexmiller19:07:48

Then change versions of the upstream deps to find a compatible set

alexmiller19:07:15

Then pester people producing those deps

alexmiller19:07:59

From a lib perspective, there are other solutions as well, like modifying the dep to use a new package root such that there is no package conflict

alexmiller19:07:37

The use of custom classloaders with dynamic classpaths can sometimes be helpful in isolating parts of the classpath from the other

zentrope19:07:30

I can revert to the earlier version of Datomic, I guess. Interesting that there’s some weird nuance such that any newer version of netty breaks datomic.

alexmiller19:07:41

would be good to report that

zentrope20:07:09

Where do I do that? The mailing list?

zentrope20:07:39

Oh, maybe there’s a support email. I can look for that when I get back.

alexmiller20:07:05

yes, either of those

zentrope22:07:28

Posted to the Datomic group. Not seeing the message. Hopefully it’s just in a moderation queue.

zentrope22:07:49

Apparently, the hornetq client depending on netty 4.0.13 is not compatible with 4.1.0, but the client using netty 3.6.7 is compatible with 4.1.0. Curious! ;)