These are chat archives for YoEight/eventstore

29th
Jan 2017
Akii
@Akii
Jan 29 2017 12:59
main :: IO ()
main = do
  con <- connect defaultSettings { s_retry = keepRetrying } (Static "localhost" 1113)
  _ <- forkIO $ forever $ catch (mksub con) (\(e :: SomeException) -> return ())
  _ <- getLine :: IO String

  return ()

  where
    mksub con = do
      putStrLn "subbin"
      sub <- subscribe con "strim" True
      putStrLn "after"
      waitConfirmation sub
      putStrLn "sub confirmed"

      forever $ do
        _ <- nextEvent sub
        putStrLn "got ev"
this will recover exactly twice
killing the store twice will result in "sub confirmed" not showing up anymore
Akii
@Akii
Jan 29 2017 13:05
now I can't even get a "sub confirmed" after the first kill :(
Akii
@Akii
Jan 29 2017 13:15
I can create an issue if you like, just wanted you to look over it in case I'm missing something obvious
\(e :: SomeException) -> return () should be \(e :: SubscriptionClosed) -> return ()
Yorick Laupa
@YoEight
Jan 29 2017 13:41

I don't get it, what do you mean by saying

this will recover exactly twice ?

On a connection drop, we abort every subscription. So not having a confirmed subscription is fined. Now I believe you'd expect waitConfirmation to throw an exception instead of a waiting forever which is fair.
Akii
@Akii
Jan 29 2017 13:50
no
I let that script run, wait until "sub confirmed" and then kill the store
re-run the store, driver reconnects
I'd expect to see "subbin\nafter" until the store is back up
then I'd expect the sub to be confirmed and go on
Yorick Laupa
@YoEight
Jan 29 2017 13:51
ok so what the recover thing is about ?
Akii
@Akii
Jan 29 2017 13:52
recovering for me is "proceed with processing events after sub aborted"
it's kinda random at this point
sometimes it works, sometimes it doesn't
Yorick Laupa
@YoEight
Jan 29 2017 13:53
ok but I don't get that part
Akii
@Akii
Jan 29 2017 13:55
what exactly don't you get?
Yorick Laupa
@YoEight
Jan 29 2017 13:55
You can create the issue if you want, but from what I see I don't get what exactly you experiencing
Akii
@Akii
Jan 29 2017 13:56
but in general this would be the "correct" way of re-subscribing to a stream, right?
catch, sub again, wait for confirmation, go processing
Yorick Laupa
@YoEight
Jan 29 2017 13:57
well waitConfirmation isn't mandatory here. I wrote it because I can.
Akii
@Akii
Jan 29 2017 13:57
noticed that it doesn't make a difference
Yorick Laupa
@YoEight
Jan 29 2017 13:57
compare to what ?
Akii
@Akii
Jan 29 2017 13:57
well in this case here leaving it out would result in the same result
Yorick Laupa
@YoEight
Jan 29 2017 13:58
that's what I said, it isn't a mandatory function.
Akii
@Akii
Jan 29 2017 13:58
good to know :D
Yorick Laupa
@YoEight
Jan 29 2017 13:58
some people may what to know the driver confirmed the sub
personally I only use it to debug when facing a bug
Akii
@Akii
Jan 29 2017 13:59
I'll just leave it out then
Yorick Laupa
@YoEight
Jan 29 2017 13:59
I heard one people asked for this type of function for the C# driver
months ago
maybe it's wrongly implemented though
Akii
@Akii
Jan 29 2017 14:01
hm, inserting a threadDelay makes it so it recovers sometimes
I really do think this is another one of "those" bugs
Akii @Akii just loves killing the store
Yorick Laupa
@YoEight
Jan 29 2017 14:01
I what I say is, give me a list of things you feel not working properly but just be precise on the issue
Akii
@Akii
Jan 29 2017 14:03
well I do my usual investigation and come up with a minimal example
this looks like a racecondition though
Yorick Laupa
@YoEight
Jan 29 2017 14:15
ok
but the race condition happens it on what feature ?
I got it's about subscription
but it has to do with how we read or how we get the subscription ?
Akii
@Akii
Jan 29 2017 14:18
I think the subscription creation is messed up
as the code above tries to create a new subscription immediately after the connection went down
if I insert a 5 second delay it almost always works
Yorick Laupa
@YoEight
Jan 29 2017 14:19
looks at your code
as soon you catch the exception, mkSub con is re-run because of the forever
Akii
@Akii
Jan 29 2017 14:19
exactly
and that might be too quick
Yorick Laupa
@YoEight
Jan 29 2017 14:20
so I don't see your point
why ?
Akii
@Akii
Jan 29 2017 14:20
my point is that it doesn't work
all I can do is observe
Yorick Laupa
@YoEight
Jan 29 2017 14:21
you put the wrong glasses :-)
Akii
@Akii
Jan 29 2017 14:21
should this code work in your opinion?
Yorick Laupa
@YoEight
Jan 29 2017 14:21
it's like you've expected one couldn't create as many subscription one wants
Akii
@Akii
Jan 29 2017 14:22
there is always just one subscription
Yorick Laupa
@YoEight
Jan 29 2017 14:22
I don't see the purpose of having a forever right after the forkIO call
Akii
@Akii
Jan 29 2017 14:23
I want to infinitely subscribe and process
Yorick Laupa
@YoEight
Jan 29 2017 14:24
that doesn't mean you want only one subscription
Akii
@Akii
Jan 29 2017 14:25
this code will create another subscription after the previous has been aborted
Yorick Laupa
@YoEight
Jan 29 2017 14:25
true
Akii
@Akii
Jan 29 2017 14:25
or am I supposed to re-use that first sub?
Yorick Laupa
@YoEight
Jan 29 2017 14:26
as 0.14.0.1 you're right, a new volatile subscription is needed
Akii
@Akii
Jan 29 2017 14:26
the behaviour of volatile subs didn't change in 0.14.0.1 I think
also note that I'm using a volatile subscription
not a catchup sub
the catchup sub will survive the disconnect
Akii
@Akii
Jan 29 2017 14:33
well didn't really investigate but seems like catchup subs die as well
they don't throw but just stop processing
anyhow, will look into this on monday or smth ^^ have a nice weekend
Yorick Laupa
@YoEight
Jan 29 2017 14:34
Nothing has changed, you're right
what I'm saying is I don't see a bug here
I don't say there nothing
just by what I currently understand (not a lot frankly), I don't see a bug
a volatile that died because of a connection drop is normal, in a sense it works as expected
if that sub isn't automatically re-started, it's also expected
Considering what I said, is there something that behaves differently ?
Akii
@Akii
Jan 29 2017 14:40
well
again, I get that the sub dies but creating a new one fails
just got another bug with catchup subs
driver sends dupes after re-connection to the store
Yorick Laupa
@YoEight
Jan 29 2017 14:41
don't had more yet because it's hard to track at the end
ok, so after the first subscription died, any further subscription creation are not working ?
you can assess this by waitConfirmation not returning, am I right ?
Akii
@Akii
Jan 29 2017 14:44
been a while since I tested it with waitConfirmation but yes it blocks there
Yorick Laupa
@YoEight
Jan 29 2017 14:44
ok
Akii
@Akii
Jan 29 2017 14:44
been testing it without it for some time now
as you said it doesn't matter
Yorick Laupa
@YoEight
Jan 29 2017 14:44
so how do you know the subscription didn't work ?
Akii
@Akii
Jan 29 2017 14:44
I push events into the store and observe the output
81723
81723
81724
81724
81725
81725
81725
81725
81725
81725
81725
81725
81725
81725
81725
81725
81725
81725
81725
81725
81726
81726
81726
81726
81726
81726
81726
81726
81726
81726
81726
81726
81726
81726
81726
81726
there are your dupes
this is another racecondition, and a bad one
Yorick Laupa
@YoEight
Jan 29 2017 14:45
again don't cross the issue you get
Akii
@Akii
Jan 29 2017 14:45
back to the sub issue 1
:D
Yorick Laupa
@YoEight
Jan 29 2017 14:46
this seems like a seperate issue
Akii
@Akii
Jan 29 2017 14:46
yes
so I sub, send events to the store, observe it's working
then I kill the store
bring it back up
Yorick Laupa
@YoEight
Jan 29 2017 14:46
so how do you know the subscription creation has failed ?
Akii
@Akii
Jan 29 2017 14:46
send events again, but no output
by sending events to the store and checking if they're processed
idk what goes wrong, but something does
Yorick Laupa
@YoEight
Jan 29 2017 14:47
ok
could you factor out a code snippet, I will look into it right now
in a github issue please
Akii
@Akii
Jan 29 2017 14:48
give me 5-10 mins to make it good
Yorick Laupa
@YoEight
Jan 29 2017 14:48
sure
I was hacking on my database :-)
Akii
@Akii
Jan 29 2017 14:49
meanwhile you can create a "testing setup" by just making sure you can send a event to a stream easily
Akii
@Akii
Jan 29 2017 15:05
#65
made it a bit fancy and again made sure the test works
the threadDelay works pretty reliable though
of course not a valid fix
but that might help you get it to work
and oh boy, catchup subs go amok ^^
Yorick Laupa
@YoEight
Jan 29 2017 15:09
thanks
Akii
@Akii
Jan 29 2017 15:09
well after this I think the driver is pretty robust :D
Yorick Laupa
@YoEight
Jan 29 2017 15:09
so if threadDelay improve the situation, it means there is a race condition indeed
I wonder if this isn't a regression
thanks again for the issue, I'm on it :-)
Akii
@Akii
Jan 29 2017 15:11
thanks for fixing :D
Akii @Akii shall be known as the killer of stores
Yorick Laupa
@YoEight
Jan 29 2017 15:12
that's a fair caption for you indeed :-)
Akii
@Akii
Jan 29 2017 15:12
:D
Yorick Laupa
@YoEight
Jan 29 2017 15:13
what about the dups showing on subscription then ?
Yorick Laupa
@YoEight
Jan 29 2017 15:24
no need to be sentimental but I really appreciate what you doing. I like to make my code more robust :-)
Akii
@Akii
Jan 29 2017 15:25
:D
that one is a bit more tricky
Yorick Laupa
@YoEight
Jan 29 2017 15:26
don't know
I'm setting up the thing
it could be a quick fix
Akii
@Akii
Jan 29 2017 15:26
it could really be related
Yorick Laupa
@YoEight
Jan 29 2017 15:26
I'm just hoping I didn't introduce any regression
Akii
@Akii
Jan 29 2017 15:27
well you didn't since this wasn't possible before
Yorick Laupa
@YoEight
Jan 29 2017 15:27
unfortunately I can't test automatically that kind of tests :-(
Akii
@Akii
Jan 29 2017 15:27
because of #61 the driver would not reconnect anyway
those bugs are bad to test for sure
maybe I can come up with a solution in time
as my first Haskell program goes to production I will need to invest heavily into testing systems
from outside and inside
Akii
@Akii
Jan 29 2017 15:33
btw, I really like finding those bugs and it teaches me a lot :D
that duplicate event thing might've been a false positive
could be that I created new catchup-subs
let me come back to that one after #65
when I get a reliable sub continuation :D
Akii
@Akii
Jan 29 2017 16:22
I hope this one isn't as tricky as the last one
Yorick Laupa
@YoEight
Jan 29 2017 16:25
Have to do some dad work first, keeping you posted
Yorick Laupa
@YoEight
Jan 29 2017 18:03
well, I can't reproduce it
it works on my laptop
I give you my code (based on yours obviously), please tell me if you have the same behavior
{-# LANGUAGE OverloadedStrings, ScopedTypeVariables, NoImplicitPrelude #-}

module Main where

import ClassyPrelude

import Database.EventStore
import Data.Aeson

main :: IO ()
main = do
  con <- connect defaultSettings { s_retry = keepRetrying } (Static "localhost" 1113)

  let js  = object ["toto" .= True]
      evt = createEvent "testing" Nothing (withJson js)

  fork $ forever $ do
    (_ :: ByteString) <- getLine
    sendEvent con "strim" anyVersion evt

  fork . forever $ handle (\(_ :: SubscriptionClosed) -> threadDelay 5000000) (mkSub con >>= process)

  waitTillClosed con

  where
    mkSub c = do
      putStrLn "making a subscription"
      sub <- subscribe c "strim" True

      waitConfirmation sub
      putStrLn "sub confirmed"

      return sub

    process sub = do
      putStrLn "processing..."

      forever $ do
        n <- nextEvent sub
        print (recordedEventNumber $ resolvedEventOriginal n)
So as you can see, I send events on a different thread
I got rid of your last getLine, I'm just calling waitTillClosed to simulate the same behavior
Akii
@Akii
Jan 29 2017 18:20
well remove the threadDelay
also sending events might influence the test result
hm I see
Akii
@Akii
Jan 29 2017 18:27
ya, replacing the threadDelay with return () introduces the problem
try it a couple of times
Yorick Laupa
@YoEight
Jan 29 2017 18:28
ok, let me try
Akii
@Akii
Jan 29 2017 18:28
making a subscription
sub confirmed
processing...

18

19

20
making a subscription
sub confirmed
processing...
making a subscription
I had some events in strim
btw, what's the difference between fork and forkIO?
Yorick Laupa
@YoEight
Jan 29 2017 18:29
in this case, this is only classy-prelude playing smart ass
Akii
@Akii
Jan 29 2017 18:29
okay
Yorick Laupa
@YoEight
Jan 29 2017 18:29
work on any MonadIO
Akii
@Akii
Jan 29 2017 18:29
btw, thanks for the reminder to use a custom prelude
Yorick Laupa
@YoEight
Jan 29 2017 18:30
np
Akii
@Akii
Jan 29 2017 18:33
I really hope you can reproduce this
Yorick Laupa
@YoEight
Jan 29 2017 18:34
nope
:-(
Akii
@Akii
Jan 29 2017 18:34
:S
Yorick Laupa
@YoEight
Jan 29 2017 18:34
I might have a lead for you though hold on
Akii
@Akii
Jan 29 2017 18:34
so you always go back to processing... and it will continue to work?
Yorick Laupa
@YoEight
Jan 29 2017 18:35
yep
here a question for you
Akii
@Akii
Jan 29 2017 18:35
first try here
Yorick Laupa
@YoEight
Jan 29 2017 18:36
what are the options of your ghc-options in your .cabal file
?
Akii
@Akii
Jan 29 2017 18:36
-threaded -rtsopts -with-rtsopts=-N
not sure if those apply to intero
Yorick Laupa
@YoEight
Jan 29 2017 18:37
damn
like me
what do you mean ? you're running it in emacs ?
Akii
@Akii
Jan 29 2017 18:37
yep
Yorick Laupa
@YoEight
Jan 29 2017 18:38
that's a major difference
Akii
@Akii
Jan 29 2017 18:38
yes but I have the same result after building and running it
Yorick Laupa
@YoEight
Jan 29 2017 18:38
however I guess that how you find out #61 am I right ?
Akii
@Akii
Jan 29 2017 18:38
sure, that as well
at some point I always build the thing and check it
Yorick Laupa
@YoEight
Jan 29 2017 18:38
could you try it a regular terminal please ?
Akii
@Akii
Jan 29 2017 18:38
sure
Yorick Laupa
@YoEight
Jan 29 2017 18:39
just in case
Akii
@Akii
Jan 29 2017 18:41
same
:/
Yorick Laupa
@YoEight
Jan 29 2017 18:41
that's suck
Akii
@Akii
Jan 29 2017 18:41
1st try again
I kill the store, restart, nothing
weird though, event sending doesn't work
Yorick Laupa
@YoEight
Jan 29 2017 18:42
I'm on my laptop which isn't very powerful
i7 6600U low voltage
Akii
@Akii
Jan 29 2017 18:42
nvm, event sending works but the sub is gone
just to be sure
you start the program, kill the store, bring it back up and then when you hit enter everything works?
Yorick Laupa
@YoEight
Jan 29 2017 18:43
I can run it on much powerful hexacore (my desktop)
Akii
@Akii
Jan 29 2017 18:44
idk if that will help
got an i7 here, 2 years old
Yorick Laupa
@YoEight
Jan 29 2017 18:44
desktop CPU ?
Akii
@Akii
Jan 29 2017 18:44
laptop
I was also able to reproduce this on my production machine
Yorick Laupa
@YoEight
Jan 29 2017 18:45
what's your system ?
Akii
@Akii
Jan 29 2017 18:47
mac os
and debian stable
Yorick Laupa
@YoEight
Jan 29 2017 18:48
archlinux for me
let's start from the begining
Akii
@Akii
Jan 29 2017 18:48
and you're certain you tried it without the threadDelay?
Yorick Laupa
@YoEight
Jan 29 2017 18:48
yes
so
1 You launch the program with store up
2 Press enter key to make sure the sub is up
3 (Seeing events coming through)
4 Shut the server down
5 Bring the server up
Do I have it right for now ?
Akii
@Akii
Jan 29 2017 18:52
nice
wait a second, confirming something
looking good
gotcha
Yorick Laupa
@YoEight
Jan 29 2017 18:53
then I confirm I can't reproduce it
Akii
@Akii
Jan 29 2017 18:53
I can confirm you confirming not to be able to reproduce it
timing is the key
Yorick Laupa
@YoEight
Jan 29 2017 18:54
'right I'm listening :-)
Akii
@Akii
Jan 29 2017 18:54
so here is the thing: I do 4)
until there everythings normal
and not a successful case depends on how fast I reboot the server
if I immediately run run-node.sh the sub will not continue
if I wait a bit and then run run-node.sh it will continue
this might be related to the threadDelay
in step 4 try killing the server and bring it back asap
Yorick Laupa
@YoEight
Jan 29 2017 18:56
that's hard to reproduce
I give it a try
Akii
@Akii
Jan 29 2017 18:56
ye
I can do this here 100% consistent
this is one tricky bug
Yorick Laupa
@YoEight
Jan 29 2017 18:58
Sorry still can't reproduce it
Akii
@Akii
Jan 29 2017 18:58
dang
Yorick Laupa
@YoEight
Jan 29 2017 18:58
I'm on xmonad so I'm really fast
when it comes to shut it down and start it right away
Akii
@Akii
Jan 29 2017 18:59
meh
seems to be kinda random here even after waiting
I can always just get it to fail
publishing works all the time
but just hangs on making a subscription
Yorick Laupa
@YoEight
Jan 29 2017 19:04
What ever I do, I'm always having processing
Akii
@Akii
Jan 29 2017 19:05
damn
so you compiled that thing without the thread delay
Yorick Laupa
@YoEight
Jan 29 2017 19:05
I'm setting up my desktop
just in case
yes I did
Akii
@Akii
Jan 29 2017 19:06
all I do is run that script, kill the store a bunch of times and am surely hitting this bug
weird..
Yorick Laupa
@YoEight
Jan 29 2017 19:06
I tried 3 times in a row
Akii
@Akii
Jan 29 2017 19:06
these kind of bugs are the worst
well try like 10 times xD
idk I get it between 1-3 tries
almost always first try
Yorick Laupa
@YoEight
Jan 29 2017 19:07
sure :-)
I did, and I still having no issue
Akii
@Akii
Jan 29 2017 19:09
not good :/
well if your desktop can't reproduce it it'll be hard
I can try reproducing this on my root
Yorick Laupa
@YoEight
Jan 29 2017 19:11
Maybe it's time to get your game up :-)
Yorick Laupa
@YoEight
Jan 29 2017 19:27
well I tried on my desktop and I unable to reproduce
Akii
@Akii
Jan 29 2017 19:37
that sucks :/
well lets put it on hold then
might need to fix this myself then
Yorick Laupa
@YoEight
Jan 29 2017 19:38
or you can give a try to fix it yourself :-)
exactly
Akii
@Akii
Jan 29 2017 19:38
ye I will
but that might take a while
Yorick Laupa
@YoEight
Jan 29 2017 19:38
I don't push you
but I can't do anything here
Akii
@Akii
Jan 29 2017 19:38
np, this is destiny
I know :D
thanks for trying
Yorick Laupa
@YoEight
Jan 29 2017 19:39

np, this is destiny

Do I hear an epic soundtrack in the back :-) ?

Akii
@Akii
Jan 29 2017 19:39
yep :D
Akii
@Akii
Jan 29 2017 20:03
can you tag 0.14.0.1?
Yorick Laupa
@YoEight
Jan 29 2017 20:33
here you go
forgot to do it when I push it onto hackage