I can't seem to find the equivalent of WaitForNonStaleResultsAsOfNow() in RavenDB 4 .NET Client API.
In previous versions this was available through IRavenQueryable.Customize(), but now it contains only WaitForNonStaleResultsAsOf() and WaitForNonStaleResults(). The WaitForNonStaleResultsAsOf() accepts only an ETag and no DateTime.
Also, I tried looking for WaitForNonStaleResultsAsOfLastWrite(), but couldn't find that either. And I couldn't replicate the behaviour myself by using IDocumentStore.GetLastWrittenEtag() since it is not present in 4.0.
Digging around a bit more I found that the last ETag would be available on the Raven.Client.Documents.Operations.DatabaseStatistics-object received as a response of the Raven.Client.Documents.Commands.GetStatisticsCommand... But I can't figure out how to issue this command in 4.0 either :(
Any help on achieving this in RavenDB 4 would be greatly appreciated.
In v4.0 you should only use WaitForNonStaleResults. It will work exactly as the WaitForNonStaleResultsAsOfNow was working. It is asking the server to wait on the query until the currently max etag of all the collections in the query.
Cutoff etag is used to check if the index has already process a
document with the given etag. Unlike Cutoff, which uses dates and is
susceptible to clock synchronization issues between machines, cutoff
etag doesn't rely on both the server and client having a synchronized
clock and can work without it.
WaitForNonStaleResultsAsOf is going to be removed from the client:
http://issues.hibernatingrhinos.com/issue/RavenDB-9678
Related
I recently came through the concept of ETag HTTP header. (this) But I still have a problem that for a particular HTTP resource who is responsible to generate ETags?
In other words, it is actual application, container (Ex:Tomcat), Web Server/Load balancer (Ex: Apache/Nginx)?
Can anyone please help?
Overview of typical algorithms used in webservers.
Consider we have a file with
Size 1047 i.e. 417 in hex.
MTime i.e. last modification on Mon, 06 Jan 2020 12:54:56 GMT which
is 1578315296 seconds in unix time or 1578315296666771000 nanoseconds.
Inode which is a physical file number 66 i.e. 42 in hex
Different webservers returns ETag like:
Nginx: "5e132e20-417" i.e. "hex(MTime)-hex(Size)". Not configurable.
BusyBox httpd the same as Nginx
monkey httpd the same as Nginx
Apache/2.2: "42-417-59b782a99f493" i.e. "hex(INode)-hex(Size)-hex(MTime in nanoseconds)". Can be configured but MTime anyway will be in nanos
Apache/2.4: "417-59b782a99f493" i.e. "hex(Size)-hex(MTime in nanoseconds)" i.e. without INode which is friendly for load balancing when identical file have different INode on different servers.
OpenWrt uhttpd: "42-417-5e132e20" i.e. "hex(INode)-hex(Size)-hex(MTime)". Not configurable.
Tomcat 9: W/"1047-1578315296666" i.e. Weak"Size-MTime in milliseconds". This is incorrect ETag because it should be strong as for a static file i.e. octal compatibility.
LightHTTPD: "hashcode(42-1047-1578315296666771000)" i.e. INode-Size-MTime but then reduced to a simple integer by hashcode (dekhash). Can be configured but you can only disable one part (etag.use-inode = "disabled")
MS IIS: it have a form Filetimestamp:ChangeNumber e.g. "53dbd5819f62d61:0". Not documented, not configurable but can be disabled.
Jetty: based on last mod, size and hashed. See Resource.getWeakETag()
Kitura (Swift): "W/hex(Size)-hex(MTime)" StaticFileServer.calculateETag
Few thoughts:
Hex numbers are used here so often because it's cheap to convert a decimal number to a shorter hex string.
Inode while adding more guarantees makes load balancing not possible and very fragile if you simply copied the file during application redeploy.
MTime in nanoseconds is not available on all platforms and such granularity not needed.
Apache have a bug about this like https://bz.apache.org/bugzilla/show_bug.cgi?id=55573
The order MTime-Size or Size-MTime is also matters because MTime is more likely changed so comparing ETag string may be faster for a dozen CPU cycles.
Even if this is not a full checksum hash but definitely not a weak ETag. This is enough to show that we expect octal compatibility for Range requests.
Apache and Nginx shares almost all traffic in Internet but most static files are shared via Nginx and it is not configurable.
It looks like Nginx uses the most reasonable schema so if you implementing try to make it the same.
The whole ETag generated in C with one line:
printf("\"%" PRIx64 "-%" PRIx64 "\"", last_mod, file_size)
My proposition is to take Nginx schema and make it as a recommended ETag algorithm by W3C.
As with most aspects of the HTTP specification, the responsibility ultimately lies with whoever is providing the resource.
Of course, it's often that case that we use tools—servers, load balancers, application frameworks, etc.—that help us fulfill those responsibilities. But there isn't any specification defining what a "web server", as opposed to the application, is expected to provide, it's just a practical question of what features are available in the tools you're using.
Now, looking at ETags in particular, a common situation is that the framework or web server can be configured to automatically hash the response (either the body or something else) and put the result in the ETag. Then, on a conditional request, it will generate a response and hash it to see if it has changed, and automatically send the conditional response if it hasn't.
To take two examples that I'm familiar with, nginx can do this with static files at web server level, and Django can do this with dynamic responses at the application level.
That approach is common, easy to configure, and works pretty well. In some situations, though, it might not be the best fit for your use case. For example:
To compute a hash to compare to the incoming ETag you first have to have a response. So although the conditional response can save you the overhead of transmitting the response, it can't save you the cost of generating the response. So if generating your response is expensive, and you have an alternative source of ETags (for example, version numbers stored in the database), you can use that to achieve better performance.
If you're planning to use the ETags to prevent accidental overwrites with state-changing methods, you will probably need to add your own application code to make your compare-and-set logic atomic.
So in some situations you might want to create your ETags at the application level. To take Django as an example again, it provides an easy way for you to provide your own function to compute ETags.
In sum, it's ultimately your responsibility to provide the ETags for the resources you control, but you may well be able to take advantage of the tools in your software stack to do it for you.
There is a ton of documentation on academic theory and best practices on how to manage versioning for RESTful Web Services, however I have not seen much discussion on how multiple REST APIs interact with data.
I'd like to see various architectural strategies or documentation on how to handle hosting multiple versions of your app that rely on the same data pool.
For instance, suppose you make a database level destructive change to a database table that causes you to have to increment your major API version to v2.
Now at any given time, users could be interacting with the v1 web service and the v2 web service at the same time and creating data that is visible and editable by both services. How should this be handled?
Most of changes introduced to API affect the content of the response, till changes introduced are incremental this is not a very big problem (note: you should never expose the exact DB model directly to the clients).
When you make a destructive/significant change to DB model and new API version of API is introduced, there are two options:
Turn the previous version off, filter out all queries to reply with 301 and new location.
If 1. is impossible to need to maintain both previous and current version of the API. Since this might time and money consuming it should be done only for some time and finally previous version should be turned off.
What with DB model? When two versions of API are active at the same time I'd try to keep the DB model as consistent as possible - having in mind that running two versions at the same time is just temporary. But as I wrote earlier, DB model should never be exposed directly to the clients - this may help you to avoid a lot of problems.
I have given this a little thought...
One solution may be this:
Just because the v1 API should not change, it doesn't mean the underlying implementation cannot change. You can modify the v1 implementation code to set a default value, omit the saving of a field, return an unchecked exception, or do some kind of computational logic that helps the v1 API to be compatible with the shared datasource. Then, implement a better, cleaner, more idealistic implementation in v2.
when you are going to change any thing in your API structure that can change the response, you most increase you'r API Version.
for example you have this request and response:
request post: a, b, c, d
res: {a,b,c+d}
and your are going to add 'e' in your response fetched from database.
if you don't have any change based on 'e' in current client versions, you can add it on your current API version.
but if you'r new changes are going to change last responses, for example:
res: {a+e, b, c+d}
you most increase API number to prevent crashing.
changing in the request input's are the same.
I'm using JMETER 2.4
I'm using HTTP request sampler with a Post action.
In this sampler, I have a parameter. The value for this parameter that I have to sent, is more than 5375 characters.
When I run this case in JMeter, the value seems to be sent from my end, but my website does not see this value.
When I check the check the received value using Fiddler the parameter is showing Empty.
After many try it seems JMeter has a limitation around 5375 characters for the parameter's value in a HTTPRequest sampler.
Do you know how to avoid this limitation?
In my opinion, you may have reached the maximum URL lenght (is 8K).
You may try if a more recent version has increased this limit, but probably even a real browser will find the same limitation.
A complete discussion about maximum URL length can be find here.
JMeter as of 2.9 has not such limitation, it respects HTTP Standard which puts a limit on a GET request length (as sbos61 pointed it).
But it seems from your question you are using POST (not GET).
Can you show your sampler configuration ?
Anyway I highly suggest upgrading to JMeter 2.9, I have just tested with this 2.9 version , and there is no problem.
Using HttpWebRequest/Response, and the Trailer headers in the chunked-encoded response are being thrown away (I've actually stepped through the .Net 4.0 reference source to see where it calls RemoveTrailers after the final chunk). Is there any way to retrieve those headers? Also, does anyone know why this behavior is in place to begin with?
In case anyone asks, no, I can't ensure that the trailer headers are moved to the rest of the headers. This is simply the data stream format I have to work with.
I dont think there is any way to do that. As to why it is like this, when this feature was first being implemented, there was no known HTTP server that sent headers in chunked response trailers.
What kind of server is this? Is this a custom server that is doing this?
If you absolutely care about this, you can find a feature request at the MS connect website (http://connect.microsoft.com).
In Silverlight I got the following problem. If you fire multiple requests to the web service, the responses might not return in an ordered sequence. Meaning if the first request takes longer than the following ones, its response will return at last:
1. Sending request A.. (takes longer for some reason)
2. Sending request B..
3. Sending request C..
4. ...
5. Receiving response B
6. Receiving response C
7. Receiving response A
Now in my scenario, I am only interested in the most recent request being made. So A and B should be discareded and C should be kept as only accepted response.
What is the best approach to manage this? I came up with this solution so far:
Pass a generated GUID as user object when sending the request and store that value somewhere. As all responses will contain their respective GUID, you can now filter out the stale responses. A request-counter instead of a GUID would work as well.
Now I wonder if there are any better approaches to this. Maybe there are any out of the box features to make this possible? Any ideas are welcome..
I take a similar approach in my non-WCF ASP.NET web services, though I use the DateTime of the request instead and then just store the DateTime of the most recent request. This way I can do a direct less than comparison to determine if the returning service is the most recent or not.
I did look into canceling old service calls before making new ones, but there is no CancelAsync call for web services in Silverlight and I have been unable to find an equivalent way of doing this.
Both of these approaches are what I took when I worked on a real time system with a lot of service calls. Basically just have some way to keep track of order ( incrementing variable, timestamp, etc. ) then keep track of highest received response. If the current response is lower than the highest, drop it.