@isaac: No, it doesn't

@casperc: I got it, thanks

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?

Seems to get hung up on create-database.

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

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

Does 5385 somehow break something running on OpenJDK 8?

Nope.

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

zentrope: is your transactor also 58385?

Yes.

ah, i see it now.

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

waacky!

Yes.

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.

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

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

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

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)

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

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

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

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

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.

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.

Usually you first try to exclude unneeded deps

Then try to find a version that is harmonious with both

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

Then pester people producing those deps

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

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

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.

would be good to report that

Where do I do that? The mailing list?

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

Got it: http://www.datomic.com/support.html. ;)

yes, either of those

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

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! ;)