Ayende @ Rahien

Justin commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 16:41:44 GMT

How is this any different than a stale index? Raven DB already has a way to communicate that your query results may be incomplete. The reason the results are incomplete is really secondary, either way you have incomplete results that can cause business logic issues. Just use IsStale and WaitForNonStaleResults and add something to RavenQueryStatistics to describe the stale reason(still indexing or shard down or ...) Think of it this way how should the application handle a down shard vs a long running index process? They both cause missing results for an indeterminate amount of time and the application should respond the same regardless by either waiting to see if the results become complete or failing the operation and notifying the user.

steve commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 15:48:15 GMT

Is there a possibility of taking some design ideas from a RAID and build the sharding out in a way that if a server goes down the remaining machines in the cluster can rebuild themselves to return full results if space allows?

Ju commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 14:58:15 GMT

What about a Maybe-like monad? I mean a session.ShardQuery method could return a enhanced type, so that the user must explicitely get the underlying collection by matching if it is partial or not. The strategy to apply next is up to him.

Scooletz commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 12:49:15 GMT

It's wrong if you want to make users use it always on per query basis. Raven should allow introducing a cross-cutting setting, registered once, to handle this situation (like in ISessionFactory, if there is one) and overriding when it's needed. Handling majority of cases in one way is what you should go for.

Rafal commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 11:36:21 GMT

update: wrong, the out parameter can't be used here because it needs to be returned after the query is executed, not before

Rafal commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 10:19:16 GMT

The desired API depends on the application. Sometimes you'll want to silently ignore shard's failure and sometimes you'll explicitly handle it. But it's not an error, it's a normal situation that some shard may be unavailable, therefore Ravens API shouldn't throw an exception. This approach (with ShardingStatus out parameter) is better than an exception but it's not very elegant as it requires you to remember to call ShardingStatus method with each query and then to add some code for handling the status returned. Besides, the out parameter is not so great for fluent interface because you don't know when it will be set. A callback function would be imho better.

Shaddix commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 10:06:52 GMT

I meant List<Error> (List of Error) but the parser broken my c# :)

Shaddix commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 10:05:08 GMT

One of the ways could be storing something like a List inside a session (or maybe even populating it to the Store), so every careful site-owner could display a big red cross on the top-right corner of the site, meaning that something bad happened :) That requires no friction at every .Query() call, but will give a sensible information about an error with only one-time setup.

Knaģis commented on API Design: Sharding Status for failure scenarios–explicit failure management

Wed, 30 May 2012 09:49:56 GMT

This approach could be ok, if omitting the method would cause an exception (a method name like AllowPartialResults() could be slightly better). It would be easier to implement than catching specific exception (where the partial results are in the exception details) - the solution that was proposed in the last post comments. But it would still ensure that the developer has to make a concious decision that the data he is retrieving is allowed to be incomplete (which is ok for blog posts, but is not ok when calculating financials). This approach could also enable certain entities to specify this automatically when the Query is called so that the decision making is left to the author of the model instead of the consumer.

Pop Catalin commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 19:45:04 GMT

Either way can be the "only" good way for a certain type of applications/ Therefore how about, add the possibility to set the default globally and allow overriding locally. But please go with the safe default ;). Those that want unsafe should opt in, not out out.

Chris Wright commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 18:32:11 GMT

As a user of ravendb, I want some way I can check the global health of my database without mucking about with exception handling. I want to be able to look in my session at the end of a request and see: was there anything that might have impacted correctness? If so, I'll throw up an alert message at the top of the page: "We might not be showing you all available data." That way, my customer support people can see that and give people the benefit of the doubt. They have the most information I can still provide, and also know that they don't have all the information they should. I don't necessarily need to know this for each query; that might be useful, but it's way too granular for most of what I need to do. I just need to know whether to put up the alert box or not. In a different context, I might want more granular options. Maybe I want to fail right away, or just check at one or two critical points if I have missing data. I think the two ways of handling I want are: - Fail immediately always, by throwing an exception. - Give me the best results possible always, and record on Session whether there are any failures. That should be a property available for me to check at any time, though if I'm using some sort of batching, I may have started an operation that is doomed and will not be reflected there. I'm not sure of anything else that would be useful.

Bundermuft commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 13:31:07 GMT

Just an alternative view would be using additional passive mirroring as, for example Greenplum offers. I.e. you have A B C nodes, B mirrors A, C mirrors B and A mirrors C. So if one of the nodes goes offline, system can continue to work (with integrity). At the API level this should come as additional metadata of the session and it should be controlled by initializing the session (fails with exception, does not fail with the exception). 99% of the time I can imagine, app should not know about the node down, rather than sysadmin should get the alarm shower.

Ayende Rahien commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 12:33:13 GMT

Jonty, Either options doesn't work. It is too big a tool, turn it on/off globally isn't helpful

Jonty commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 12:05:37 GMT

Why not make it configurable? Safe by default would probably mean throw the exception (with the results), but give the option to change that behaviour.

Giedrius commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 10:09:28 GMT

Hm, what about classic saving all relevant data in single shard? In such case client and all his orders/payments/etc would go to single shard and either he would get everything, either nothing, but other clients would still be able to access system.

Thomas Krause commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 10:01:42 GMT

Yes, that is the downside. The alternative would be to return a result always but include some error details in the result. But this makes it very easy to silently ignore the error. It probably depends on the application which scenario is more desirable.

alexidsa commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 09:56:51 GMT

What if put "AllNodesAreOnline" flat into statistics? In this we could find out whether query was executed correctly similar to how we get total results count for paging (http://old.ravendb.net/faq/total-results-in-paged-data-set)

Ayende Rahien commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 09:53:03 GMT

Thomas, Wow! That is something that I would have never though of. Interesting approach, and something that I might well utilize in the future. It nicely handle the scenario of getting the data and not avoiding the error, but it doesn't actually work in practice. It means that you have to be very careful about what you are doing, and that a single place where you forgot to do this would result in your site being effectivley down.

Thomas Krause commented on API Design: Sharding Status for failure scenarios–ignore and move on

Tue, 29 May 2012 09:48:33 GMT

How about throwing an exception but including the partial results in the exception details? Like this you force the calling code to handle this scenario. It can then show a message to the user ("due to technical problems some information may be missing") along with the partial results.

Ayende Rahien commented on API Design: Sharding Status for failure scenarios

Wed, 30 May 2012 07:33:07 GMT

Steve, Now what happens when you do a Load instead of Query?

Steve Py commented on API Design: Sharding Status for failure scenarios

Tue, 29 May 2012 22:27:16 GMT

To throw something out there: I'm assuming that session.Query() returns IEnumerable. Extend IEnumerable into something like IIncompleteEnumerable which includes a Reason and/or Exception. Consumers should use methods to consume the results by either IIncompleteEnumerable or IEnumerable with the former handing off to the later once it takes action with the reason. (prompt the user, fire off an e-mail, what-have-you) Unfortunately I believe you will always run into the case where such a scenario will either be "in your face" in the sense of blocking the application, or easily ignored by accident. Can you have your cake and eat it too?

Andrew Armstrong commented on API Design: Sharding Status for failure scenarios

Tue, 29 May 2012 06:50:58 GMT

I'd imagine for some results you could do with a missing shard server (eg, no specific order or limit), however I assume you may need to indicate to RavenDB that inconsistent results are permitted.

Christopher Wright commented on API Design: Sharding Status for failure scenarios

Mon, 28 May 2012 14:44:18 GMT

If a third of the data isn't available, you return the top 20 results of what you still have. In order to implement a query like this with an unknown shard strategy, each server needs to return 20 results. If you try getting clever, you either need to be really clever (and probably lose out in efficiency in the end, unless you precompute appreciably), or you end up returning stuff in the wrong order sometimes. If you're using a shard strategy which lines up with your query ordering, and have been since the beginning of time with the same number of nodes (or you rebalanced recently), you can actually query ceil(Take / #nodes) from each node. This doesn't come into play here in any case; PublishedAt is not related to insertion order. It also doesn't matter much if you have a small number of not terribly huge documents -- though here, if you have a very popular blog, you might get several hundred comments per post, so it might be worthwhile.

Paul Stovell commented on API Design: Sharding Status for failure scenarios

Mon, 28 May 2012 10:38:08 GMT

@Simon, since RavenDB uses HTTP you can probably achieve that monitoring using any HTTP monitoring solution.

Simon Hughes commented on API Design: Sharding Status for failure scenarios

Mon, 28 May 2012 09:26:44 GMT

This should be configurable IMHO. Either: * Return what you can for the above select, or * Return nothing. There should be some sort of DB and Shard monitor that checks to make sure its online and working ok, and warn admins if its off-line via SMS/Email/etc.

Phillip Haydon commented on API Design: Sharding Status for failure scenarios

Mon, 28 May 2012 09:16:16 GMT

:( Sometimes I wish your blog posts weren't broken up into 15 posts, by the time it get's to the good stuff I've forgotten the rest and/or lost interest.

Ayende Rahien commented on And this is Ironic

Sat, 26 May 2012 07:23:06 GMT

Rob, Actually, we do have a customer that is running RavenDB as the backend for a messaging system with > 30,000 users.

Rob White commented on And this is Ironic

Fri, 25 May 2012 13:54:01 GMT

How would a ravendb backed email client cope, presumably much quicker. It might be an interesting use-case.

Gene Hughson commented on And this is Ironic

Fri, 25 May 2012 13:43:20 GMT

"We have received no reports of errors" ;-) Dear Mozilla: Paging is your friend

Rippo commented on And this is Ironic

Fri, 25 May 2012 09:23:43 GMT

Always nice to have message asking to report performance, and from a support technician perspective even better not to be able to get it ;)