--- Log opened Wed Sep 30 00:00:22 2009
13:43 < jbe> I get a 404 trying to retrieve the happs development branch: http://patch-tag.com/publicrepos/happstack
14:13 < mightybyte> Yeah, the patch-tag URLs recently changed.
14:15 < mightybyte> The new URL should be http://patch-tag.com/r/mae/happstack/pullrepo
14:21 < sm> ick, still this /pullrepo silliness ?
14:22 < mightybyte> I don't know.  That's just what I saw on the patch-tag page for happstack.
17:10 < jbe> mightybyte: That works.  Thanks.  I created an issue to fix it: http://code.google.com/p/happstack/issues/detail?id=108
21:37 < mightybyte> Anyone gotten an error "Couldn't find handler for event of type: ..."?
22:14 < stepcut> mightybyte: all the time
22:14 < stepcut> probably need to add something to a, type Dependencies = ... :+: End
22:14 < mightybyte> Hmmmm....
22:14 < stepcut> or...
22:15 < stepcut> if you removed/changed a state update/query function but didn't restore from a checkpoint, then it might be trying to replay the method you changed/removed
22:15 < mightybyte> Yeah, I think that's it.
22:15 < mightybyte> That puts me in a bit of a bind.
22:16 < mightybyte> I did some significant refactoring of my state.
22:16 < mightybyte> And in the process I renamed some of the methods.
22:16 < stepcut> do you not automatically checkpoint on shutdown?
22:17 < mightybyte> Even if I hadn't renamed them, the methods would have been changed which seems like it might have corrupted data.
22:17 < mightybyte> Yes, I checkpoint on shutdown.
22:17 < stepcut> if you restore from a checkpoint, then you should mostly be fine
22:18 < mightybyte> Hmmm, let me see whether my current state points to a checkpoint or an events file.
22:19 < stepcut> oh. I should have asked another question
22:19 < stepcut> *when* do you get this error? On restore? Or when servicing an incoming request?
22:19 < mightybyte> When I start up the binary for the new version.
22:19 < stepcut> ok
22:20 < mightybyte> My current file contains ce (206), which is the number of my last checkpoint file.
22:20 < mightybyte> But I also have events-205, 206, and 207.
22:20 < mightybyte> Although events-206 and 207 are 0 bytes.
22:21 < stepcut> yeah, those are probably query events -- I never understood why they got written at all
22:21 < mightybyte> So I wouldn't think there are any events being replayed.
22:21 < stepcut> did you change the names of your types as well? Or just your methods?
22:21 < mightybyte> Yeah, I changed the types around, but I think I migrated them properly.
22:22 < stepcut> did you change the names of any types which are used in an instance Component declaration? as in, instance Component IChangedThisName where ...
22:22 < stepcut> or move any types of that nature to a different file?
22:22 < mightybyte> Don't think so.
22:23 < mightybyte> I have data AppState = AppState { ... } which is my top level instance of Component.
22:23 < stepcut> is that the only Component you have ?
22:23 < mightybyte> The types I changed are members of AppState.
22:23 < mightybyte> No
22:23 < mightybyte> But none of the other components got changed.
22:24 < stepcut> hrm
22:26 < stepcut> in happstack state, there is a table which maps type names to functions that handle them. The error means it encountered a type name when restoring the state that no longer has a mapping to something which can handle it
22:27 < stepcut> the type names it cares about are the types which represent methods (aka, the types generated by mkMethods)
22:27 < mightybyte> Does it need to restore those methods when reading a checkpoint?
22:27 < stepcut> and the types of the Components
22:27 < stepcut> when restoring from a checkpoint, I don't believe that any update/query methods should be invoked
22:29 < stepcut> I know that error can occure when you change the name of a method, and then on restore also replay events that use the old name
22:29 < stepcut> it can also occured if you emit events from Components which are not somehow referenced by the top-level Component
22:31 < stepcut> the other issue is that for Components-only, the fully qualified name of the type is saved in the checkpoint. Aka, MyApp.Foo.Bar.MyComponentType
22:31 < mightybyte> The name referenced is the name of a method.
22:31 < stepcut> if you move the type from one module to another, or rename it, then it can not find it
22:32 < stepcut> is it a method that you changed ?
22:36 < mightybyte> Yes.  It's the old name of one that was renamed.
22:36 < stepcut> so, it sounds like events are being replayed for some reason, even though you ought to just be restoring from a checkpoint file.
22:37 < stepcut> making sure that the very last thing that happens is a checkpoint is actually somewhat tricky
22:37 < mightybyte> Yeah
22:37 < mightybyte> Well it seems like that is the case here.
22:38 < stepcut> creating checkpoints is not a blocking operation. So, if other threads are still running and processing things when you create a checkpoint and shutdown, some other events could be written
22:38 < stepcut> are you using hslogger?
22:38 < mightybyte> Ahh.
22:38 < mightybyte> Yeah for some things.
22:39 < stepcut> with the write setup, hslogger might tell you if events are being replayed when you reload .. not sure though.
22:40 < stepcut> I guess I would copy the state directory, and see what happens if you remove everything but your last current and checkpoint file :-/ (and tweak current if required)
22:40 < mightybyte> Yeah, I was thinking about that.
22:40 < stepcut> I don't know a great way to ensure that all events are truely flushed when creating a checkpoint
22:40 < mightybyte> I've got my state directory in git...(which is turning out to have been a good move).
22:41 < stepcut> you can first kill the simpleHTTP thread, so that no new request are processed, but there is no way to know if the existing requests have finished yet.
22:41 < mightybyte> Yeah
22:41 < stepcut> killing simpleHTTP, waiting a second or two, and the doing the createCheckpoint might do it
22:43 < stepcut> heh. It looks like happs already had some daemonization code for creating a locking file to prevent multiple instances from running...
22:43 < mightybyte> Let me just try creating another checkpoint from the live site and see if that has the same problem.
22:44 < mightybyte> So if you create a checkpoint and then a few new events get written after that, will those events be in a higher-numbered event file?
22:45 < stepcut> I would think so...
22:46 < stepcut> there is some code in Happstack.Util.Concurrent which I think can be used to kill all the background threads. But I am not sure if it is actually in use..
22:49 < stepcut> anyway, you have somehow offended happstack-state's delicate sensibilities. :)
22:50 < mightybyte> Yeah.  I'm quite disappointed.  I was thinking that I had the migration carefully thought out.
22:50 < stepcut> there is some undocumented process you should have followed to avoid it, but no one knows what it is yet :-(
22:51 < mightybyte> Well, it seems like the process I'm following should have been that.
22:51 < stepcut> yeah, I would like to know what happened because it sounds like you did everything right
23:12 < mightybyte> Hmmm, it appears that the problem went away with the new checkpoint.
23:12 < mightybyte> Seems like your checkpoint theory is probably right.
23:48 < stepcut> ok
23:49 < mightybyte> Once my revenue is substantial enough, I'll probably axe the ads.
23:50 < mightybyte> Opps, wrong window.
23:52 < stepcut> I think that's google's plan too ;)
23:52 < mightybyte> lol
--- Log closed Thu Oct 01 00:00:22 2009