Servlet 3.0 和 Comet/long-polling：在这些特定场景中会发生什么？
我看了一下Servlet 3.0实现服务器推送的简要概述 这里，留下的问题比我进来时还要多。这些问题与我的用例相关：在“朋友”之间实现动态通知系统，如 Facebook。从概念上考虑这个问题，我会这样处理：
- 在每个中放置一个无限的 jQuery 循环 页面，包含发出的代码 XMLHttpRequest“获取”请求 服务器
- 允许服务器存储 相关的请求/响应对象 这些类型的 XMLHttpRequests 在 应用程序范围的映射（带有 AsyncContext 的帮助和 .startAsync())，由用户键入 网站 ID
- 每当用户进行某项操作时 产生通知，查询 应用程序范围的 ID 映射 用户的朋友，并使用 响应对象存储在那里，发送 通知每位朋友。
- 每位好友都会收到 通知和无限循环 在他们所讨论的页面上 再次 XMLHttpRequests（由于无限循环）
假设我的系统在概念上是健全的（如果不是，请告诉我出了什么问题），我在这个系统中发现了几个问题：
请求/响应 响应后在地图中配对 被使用？我应该手动 将其从地图中删除，或者等待 客户端循环发送 另一个请求，因此存储 请求/响应对象对可以是 替换为与关联的对 新的 XMLHttpRequest？链接 上面使用了“承诺”一词，并且 “未承诺”指的是 响应对象。有人可以吗 解释一下这些词的意思 这个背景（我有一种感觉 它们与人的寿命有关 响应对象）？
如果用户的两个或多个朋友同时进行导致通知的操作，会发生什么情况？每个用户仅存储一对请求/响应。无论哪个朋友的操作恰好找到了相关请求/响应对中的用户，都会收到发送给该用户的通知，但是其他朋友的操作呢？如果它们全部同时发生，则其他操作将不会有请求/响应对用于发送通知，直到用户发送另一个要存储在地图中的 XMLHttpRequest。据推测，其他操作将解析映射，并且找不到该用户的条目（因为在其他操作使用响应后它被手动删除），或者找到已使用的“陈旧”请求/响应对象。我假设一个响应对象不能用于两个不同的响应，那么有人会如何纠正这个问题呢？
如果通知是 当用户处于 切换页面？如果我们完整地查看 作为打开的窗口加载网页 用于接收通知请求， 和一个正在加载的窗口作为关闭的窗口 （因为无法接收和 处理响应 之前发送的 XMLHttpRequest 页），期间发送的通知 这个时间范围将会丢失。是 我还能做些什么 查询数据库是否有新的 操作并生成通知 页面加载时就是这样？
最后，当用户 导航离开该网站和 会话过期？我们是否期望 定期迭代地图 并删除与关联的请求 没有现有会话？
抱歉，如果这是一篇很长的文章。即使您只能回答上述问题之一也会有所帮助！
I took a look at a brief overview of Servlet 3.0's implementation of server push here and left with more questions than I came in with. The questions are related to my use case: implementing a dynamic notification system amongst "friends", a la Facebook. Conceptually thinking about the problem, I would approach it as so:
- Put an infinite jQuery loop in each
page, containing code to issue an
XMLHttpRequest "get" request to the
server - Allow the server to store the
request/response objects related to
these type of XMLHttpRequests in an
application-scoped map (with the
help of AsyncContext and
.startAsync()), keyed by the user's
website ID - Whenever a user engages in an action
that spawns notification, query the
application-scoped map for IDs of
the user's friends, and using the
response objects stored there, send
the notification to each friend. - Each of the friends receive the
notification, and the infinite loop
on the pages they're on issue
XMLHttpRequests again (due to the infinite loop)
Assuming my system is conceptually sound (and if it isn't, please tell me what's wrong), there are a couple of issues that I see with this system:
What happens to a request/response
pair in the map after the response
is used? Am I supposed to manually
delete it from the map, or wait for
the loop on the client side to send
another request so the stored
request/response object pair can be
replaced by the pair associated with
the new XMLHttpRequest? The link
above uses the words "committed" and
"uncommitted" in reference to
response objects. Can someone
explain what those words mean in
this context (I have a feeling
they're related to the longevity of
the response objects)?What happens if two or more of a user's friends engage in actions that cause notifications at exactly the same time? There is only one request/response pair stored per user. Whichever friend's action happens to find the user in question's request/response pair gets its notification sent to that user, but what about the actions from the other friends? If they all happen at the same time, then the other actions won't have a request/response pair to use to send a notification until the user sends another XMLHttpRequest to be stored in the map. Presumably other actions will parse the map and either find no entry for that user (because its been manually deleted after the other action used the response), or find a "stale" request/response object that has already been used. I'm assuming that a response object can't be used for two different responses, so how would somebody go about rectifying this?
What happens if a notification is
sent to a user when the user is
switching pages? If we view a fully
loaded web page as an open window
for receiving notification requests,
and a loading one as a closed window
(because it is unable to receive and
process responses to the
XMLHttpRequests sent by the previous
page), the notifications sent during
this time frame will be lost. Is
there anything I can do short of
querying the database for new
actions and generating notifications
that way on page load?Finally, what happen when a user
navigates away from the site and the
session expires? Are we expected to
periodically iterate through the map
and delete requests associated with
no existing sessions?
Sorry if this was a long read. Even if you can only answer one of the above questions it would help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
响应可能会一直保留到超时为止。你不断地一遍又一遍地推送新信息。这就是彗星。您不会永远循环获取请求，而是处理从服务器流式传输的数据，1 个获取请求将持续到超时，然后在完整的函数中发出另一个获取。
同样，响应仍然可用，您只是在上面写入，而不是每次都关闭它。
一种方法是为所有通知添加时间戳，并使用特定时间的数据加载页面，然后您的初始获取请求提供时间戳，然后您就可以了解最新情况。
我再次假设，你按住它直到超时。
因此，为了更好地解释这里发生的情况，
The response is kept until it times out probably. you keep pushing new info on it over and over again. That is what comet is. You don't loop get requests forever, you handle the data that is streaming from the server as it comes, 1 get request will last until it times out, then in the complete function issue another get.
Again, the response is still available, you are only writing on it, not closing it every time.
One way would be to timestamp all notifications and load the page with data from a certain time, your initial get request then provides the timestamp and you are then up to date.
I assume again, you hold it until it times out.
So just to better explain what is happening here,