I am using spring-session and wondering how to know a specific session expired.
Querying Redis persistence, I find a couple of the following lines
[ root#redis-master-6fbbc44567-cc28m:/data ]$ redis-cli
127.0.0.1:6379> keys *
1) "spring:session:expirations:1581796140000"
2) "spring:session:sessions:23d6aff1-cb43-44f6-920d-cc3536ab6d46"
127.0.0.1:6379>
Converting the expirations to date, they are equavalent to Mon 14 Feb 52095 16:40:00 GMT which looks weird at the year.
We might extract the expired time from HttpSession:
HttpSession httpSession = request.getSession()
long currTime = System.currentTimeMillis()
long expiryTime = currTime + httpSession.getMaxInactiveInterval()
But the snippet doesn't show exactly what weed anticipate.
I reckon we need to retrieve expirations from Redis server instead.
What am I doing wrong here?
Any of you know how to retrieve sessions and expirations from Redis?
The expiration timestamp 1581796140000 is a Unix epoch in milliseconds and translates to GMT: Saturday, February 15, 2020 7:49:00 PM.
Related
I am trying to get a handle on the interaction between DateTime.Now and ISO-8601 timezone designation for an API I am working on. An endpoint incorporates a timestamp as criteria for the interrogation of our data historian. The EndPoint returns the nearest previous 1/2 hour average for the datapoint requested and incorporates the following code:
If criteria.EndTime = "" Then
timeStamp = DateTime.Now
Else
timeStamp = CType(criteria.EndTime, DateTime)
End If
The body of the post accepts the following json:
{
"Interval": "30m",
"StartTime": "",
"EndTime": "2022-04-21T00:45:00Z",
"TagList": "PointName",
"Delim":",",
"PointSource": "P",
"ServerName": "PIServer"
}
Where the EndTime is the parameter picked up by the endpoint. We are currently in British Summer Time i.e. DST is UTC +01:00. With the above criteria the data I get back is timestamped as follows:
[
{
"PointName": "PointName",
"TimeStamp": "21/04/2022 01:30:00",
"Value": "-2.3607"
},
{
"PointName": "PointName",
"TimeStamp": "21/04/2022 01:30:00",
"Value": "-2.6333"
}
]
As you can see the data returned is for 01:30 rather than the 00:30 that is expected. If I leave the 'Z' designation out of the criteria then I get the correct content returned. Can someone explain what is happening here please.
Let's assume the client sent UTC based time (yours is) and the server responds in UTC time (it does not). As described, ...T00:30:00Z (00:30:00 UTC) is the correct answer to your input of ...T00:45:00Z based on what you said the endpoint does.
Now let's say the server responds in BST (which, it seems to) to the same UTC based client request. Then ...T01:30:00 (no time zone designation, assumed to be BST) is the correct answer for your input because 00:30:00 UTC is equivalent to 01:30:00 BST, which is the correct result given the server's rules.
I think you've missed the fact that the server appears to always be returning BST (perhaps that's local to the server) without a time zone designation (i.e. you could argue it should be returning T01:30:00+1:00)
It appears that if you send UTC (or any other time with time zone info), you get a BST response with no time zone designation, and if you send a time with no time zone info, the server assumes you're sending BST, and still returns BST.
So, when you remove the Z from your request, you get what you think is the wrong answer, but isn't because T00:45:00 (aka 00:45:00 assumed BST) the server will respond with T00:30:00 (aka 00:30:00 assumed BST).
I suspect if you sent T00:45:00+1:00 you'd get back T00:00:00+1:00, but if you don't (i.e. no to zime zone info), then it might be a server bug. You could test this by sending T00:45:00+2:00 and seeing if you get back T00:00:00+2:00 or not.
I already set celery4.4 config timezone is "Asia/Shanghai"
CELERY_TIMEZONE = "Asia/Shanghai"
And the terminal show now datetime.
2021-08-20 23:26:03,849
But the backend I use redis date_zone is not the same as the datetime now.
"date_done": "2021-08-20T15:26:03.848352"
I dont know where my config is wrong.
Currently as documented, the resulting date_done isn't based on the configured Celery timezone but rather is just always UTC. That is why you are seeing 15:26 (UTC) instead of 23:26 (UTC+8).
https://docs.celeryproject.org/en/stable/reference/celery.result.html#celery.result.AsyncResult.date_done
https://docs.celeryproject.org/en/stable/internals/reference/celery.backends.database.models.html
property date_done
UTC date and time.
This feature has already been requested before but seems to be always de-prioritized and moved for next release. Currently, it is planned to be included in Celery 5.2.
The celery result column, date_done is utc, even though you set the timezone
I have an API where I have created a token and it has replied with.
expires_in=7776000
created_at=1463347242
expires_in seems to be seconds (also what the spec calls for) 7776000 / 60 / 60 / 24 = 90 days
However I have no idea how to even begin to decode the created_at response and the endpoint doesn't have any documentation on it.
The created_at value is just the unix timestamp in seconds the token was created at. In your case it is the RFC 2822 date Sunday, 15-May-16 21:20:42 UTC. For this field I couldn't find a specification, but it seems to be a common field to many implementations. With it you can calculate the absolute timestamp of expiration: expires_at = created_at + expires_in
When a server gives Cache-Control: max-age=4320000,
Is the freshness considered 4320000 seconds after the time of request, or after the last modified date?
RFC 2616 section 14.9.3:
When the max-age
cache-control directive is present in a cached response, the response
is stale if its current age is greater than the age value given (in
seconds) at the time of a new request for that resource. The max-age
directive on a response implies that the response is cacheable (i.e.,
"public") unless some other, more restrictive cache directive is also
present.
It is always based on the time of request, not the last modified date. You can confirm this behavior by testing on the major browsers.
tl;dr: the age of a cached object is either the time it was stored by any cache or now() - "Date" response header, whichever is bigger.
Full response:
The accepted response is incorrect. The mentioned rfc 2616 states on section 13.2.4 that:
In order to decide whether a response is fresh or stale, we need to compare its freshness lifetime to its age. The age is calculated as described in section 13.2.3.
And on section 13.2.3 it is state that:
corrected_received_age = max(now - date_value, age_value)
date_value is the response header Date:
HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response was generated [...] We use the term "date_value" to denote the value of the Date header.
age_value is for how long the item is stored on any cache:
In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus the amount of time it has been in transit along network paths.
This is why good cache providers will include a header called Age every time they cache an item, to tell any upstream caches for how long they cached the item. If an upstream cache decides to store that item, its age must start with that value.
A practical example: a item is stored on the cache. It was stored 5 days ago, and when this item was fetched, the response headers included:
Date: Sat, 1 Jan 2022 11:05:05 GMT
Cache-Control: max-age={30 days in seconds}
Age: {10 days in seconds}
Assuming now() is Feb 3 2022, the age of the item must be calculated like (rounding up a bit for clarity):
age_value=10 days + 5 days (age when received + age on this cache)
now - date_value = Feb 3 2022 - 1 Jan 2022 = 34 days
The corrected age is the biggest value, that is 34 days. That means that the item is expired and can't be used, since max-age is 30 days.
The RFC presents a tiny additional correction that compensates for the request latency (see section 3, "corrected_initial_age").
Unfortunately not all cache servers will include the "Age" response header, so it is very important to make sure all responses that use max-age also include the "date" header, allowing the age to always be calculated.
This is similar to the question: GWT Data Serialization
I am using Date Object # my client,
Here is what I tried,
I created a Date Object, showed its toString() in a Label and passed it to server via Rpc whose return value is the same Date's toString()
value passed:
Date value = new Date(2011, 0, 19);
Output # Hosted/Development mode : (http://127.0.0.1:8888/MyApplication.html?gwt.codesvr=127.0.0.1:9997)
Client Reads: Thu Jan 19 00:00:00 IST 3911 Server reads:Thu Jan 19 00:00:00 IST 3911
Output # Production mode (after GWT compile) : (http://127.0.0.1:8888/MyApplication.html)
Client Reads: Thu Jan 19 00:00:00 GMT+530 3911 Server reads:Thu Jan 19 00:00:00 IST 3911
Output # Deploying in Jboss running in the same Machine :
Client Reads: Thu Jan 19 00:00:00 GMT+530 3911 Server reads:Wed Jan 18 18:30:00 GMT 3911
What's mind boggling is that its the same machine and hence the locale, etc should ideally be the same, still # hosted mode I see client sends IST server receiving IST, #production I see client sends GMT server receives IST and #Jboss server deploy I see client sends GMT and server receives GMT with one Day less !!
The fact that the server recieves one day less is very seriously affecting my application business logic, basically I am using iBatis thats populating my pojos from database and sending it to client and at client I am using GXT which is showing me a UI for date selection.
Using String for date is not suitable for me since its a major change in application core pojos, all database select and insert queries just because my client library does not handle Dates well.
Does anyone have a alternative to this ?
You can try to use DateTimeFormat to build something that is unambiguous among machines despite locales. Format like 'yyyy-MM-dd HH:mm:ss ZZZZ' instead of using toString()
Date today = new Date();
DateTimeFormat fmt = DateTimeFormat.getFormat("yyyy-MM-dd HH:mm:ss ZZZZ");
GWT.log(fmt.format(today));