Fork me on GitHub
#datomic
<
2015-07-14
>
robert-stuttaford07:07:57

@wilkerlucio: @arohner: you can also use d/with to dry-run the transaction and check that (-> tx-result :tx-data count (> 1)) to know if there will be any changes

robert-stuttaford07:07:15

there will always be one datom for the tx timestamp

robert-stuttaford07:07:29

we do this in our Onyx stats processing system to reduce noise

wilkerlucio10:07:17

@robert-stuttaford: cool, I'll try that approach, thanks

Lambda/Sierra12:07:02

@wilkerlucio @arohner A transaction which re-asserts existing facts will create a new Transaction entity in the log, but it will not contain the re-asserted Datoms.

wilkerlucio12:07:20

@stuartsierra: thanks, that's nice to know

robert-stuttaford12:07:20

@bkamphaus: do you perhaps know why peer would connect to 127.0.0.1 even though i’m giving it an FQDN which resolves to the IP of a different server on the dev storage? driving me nuts!

robert-stuttaford12:07:20

bit of a shotgun approach, but trying @luke and @daemianmack too simple_smile

robert-stuttaford12:07:51

the docs clearly show that a host must be provided:

robert-stuttaford12:07:54

Dev Appliance: datomic:dev://{transactor-host}:{port}/{db-name}

luke12:07:45

Well, first of all, definitely.not.localhost is in fact a subdomain of localhost 😄

luke12:07:56

But I'll presume that's not actually the string you're using

robert-stuttaford12:07:06

yes simple_smile not the real string

robert-stuttaford12:07:18

i can ping the actual domain from the server in question and it resolves to the right IP

luke12:07:41

Hm. Aside from some crazy networking nonsense I can't think of anything that would cause that.

luke12:07:18

Can you temporarily change the port on your db connection string to something else? Then your error message would show whether its somehow resolving your domain to localhost, or using a different config entirely.

robert-stuttaford12:07:21

i was using /etc/hosts shortcuts before. let me make very sure it’s not a factor

luke12:07:39

yeah overriding in hosts would definitely explain what's going on.

robert-stuttaford12:07:02

ok. /etc/hosts eliminated. still happening

robert-stuttaford12:07:17

yes. i’ll alter the port

robert-stuttaford12:07:51

so now it’s attempting the domain

robert-stuttaford12:07:08

with 4334 it’s back to localhost again

luke12:07:26

That's strange. It could be a bug in Datomic, but Occam's razor says its something with how your application code is loading the connection string. A caching effect, or something. Maybe restart the JVM process if you haven't already? Put a println immediately before you call datomic.api/connect at the lowest possible level?

luke12:07:42

sorry, don't have any really good ideas.

robert-stuttaford12:07:53

if the transactor machine’s firewall is not allowing connections, perhaps the code that reports this error isn’t reporting the right string for domain?

robert-stuttaford12:07:22

the strace has hornetq close to the throw. perhaps it’s in HQ.

robert-stuttaford12:07:30

trying to validate the firewall rules independently now

luke12:07:04

actually, @robert-stuttaford, looking at the error messages, I think your first one isn't a problem with hitting storage at all

luke12:07:22

look how the error comes from h2.jdbc when you change the port, but is a standard wrapped exception if the port is correct

robert-stuttaford12:07:35

yeah, it’s a hornetq strace; it’s trying to connect to the transactor

robert-stuttaford12:07:16

ok. i’m pretty sure it’s a blocked nostril <BACKSPACE> port. thank you for the rubber ducking and apologies to all for the channel noise

Ben Kamphaus12:07:22

@robert-stuttaford: the host in the URL is the storage host, the transactor writes its location in storage and then the peer connects to the transactor. What’s the host in the transactor properties file?

Ben Kamphaus12:07:48

Sorry if I missed any details there, just a quick scan.

robert-stuttaford12:07:59

that’s exactly where i’m debugging now. it’s 127.0.0.1. it should be the public ip, right?

robert-stuttaford12:07:05

or can i cheat and use 0.0.0.0

tcrayford12:07:50

number of bugs I've worked on at $dayjob this month that would be trivial to fix if we'd used datomic instead of postgres: 40. Fuck databases without history and transaction metadata

tcrayford12:07:21

(nearly all of those take the form "which part of this 50k lines of code is modifying this data incorrectly")

Ben Kamphaus12:07:05

@robert-stuttaford: it should be an ip the peer can connect to the transactor with simple_smile if you’re using e.g. a container or virtual instance that doesn’t know its IP until running, you might have to look into something like e.g. https://groups.google.com/d/msg/datomic/wBRZNyHm03o/0SdNhqjF27wJ

robert-stuttaford12:07:38

great, thank you ben. nice gas mask, by the way simple_smile

robert-stuttaford12:07:23

that explains why I saw 127…. now. it was fetching that value from storage (which it could reach), and the transactor had put 127 there because of the props file

ghadi18:07:28

To confirm a bit of undocumented knowledge http://docs.datomic.com/clojure/index.html#datomic.api/connect For a SQL backend, any connection pooling needs to be handled in userspace by providing the appropriate :datasource, right?

ghadi18:07:04

And is connection pooling even necessary?

ghadi18:07:50

The latter question is more important.

val_waeselynck20:07:07

If anyone can be of help simple_smile

mitchelkuijpers20:07:25

@val_waeselynck basically it is use conformity and read the blogpost from @tcrayford that's how I got it working simple_smile

val_waeselynck20:07:35

@mitchelkuijpers: thanks for the quick answer simple_smile I'll give it a try then validate your answer

mitchelkuijpers20:07:42

@val_waeselynck no problem if you need any more help let me know