问题标签 [backlog]

是否有任何理由更喜欢 TFS 中的显式积压区域或迭代节点，而不是仅使用根节点？这是否改善了任何报告或任何东西的功能？它们中的任何一个都提供更容易的可管理性吗？

我已经看到了这两种方式，我希望看到有关权衡的建议。

使用netty编程时，出现一个问题：“控制已建立的最大连接数”有没有这样的方法可以实现这个功能？

就像：“serverBootstrap.option(ChannelOption.SO_BACKLOG,100);” 用于设置未接受队列连接的最大数量。

我们的 Jira 中有 1000 多张旧票，其中大部分是我们永远无法到达的。如果我们愿意，我们可以最容易地把它们从积压中隐藏起来的最好方法是什么？

想法：

• 给他们一个标签，然后完成他们不会修复
• 创建一个特殊的“存档”项目并将它们移到那里

这些优点和缺点？其他想法？

试图了解我在 TFS 2012 Web Access 中看到的 WORK | 积压 | 产品待办事项，我使用“创建待办事项查询”按钮，然后在编辑中打开新查询以查看它是如何工作的。我注意到它显示了符合两种描述的 PBI：

• PBI 在根迭代（积压）下处于 New/Approved 状态的任何位置。
• 待办事项（根迭代）中的 PBI 处于 New/Approved/Committed 状态。

为什么 PBI 符合第二个描述？为什么 PBI 会在 backlog 中提交？是否可以通过某种方式在改进后维护主题或史诗级别的 PBI，并在他们的用户故事级别的孩子致力于真正的 sprint 时将它们设置为承诺？它是否可能只是一种补偿伪劣簿记的手段，其中不完整的 PBI 被踢到积压但没有将其状态恢复为已批准？也许还有其他原因？

我有以下脚本：

该脚本用于即时搜索类型场景（如 Google），因此当用户在文本框中键入时，它会向服务器发送相当多的选择请求（尽管我已经使用 pconnect，因此没有重复的数据库连接）。

它是一个相当大的数据库，每次击键都作为 AJAX 请求发送，因此最终会出现大量待处理请求的积压。我希望它在每次发送新请求时停止/取消所有先前的请求（如果它们没有被发回）。

我看过xhr.abort()但我很确定这只会停止任何尚未发送的请求（而不是告诉服务器停止处理）。这可能没问题，但我仍然不知道如何在我的代码中实现它。

How to migrate backlog items from VersionOne to TFS 2012 (when details contains images) I created an excel export but the VersionOne Description that is being imported to the TFS Work Item Details contains images. Both products allow images.. How would you migrate the images with the workitems?

尽管关于这个话题说了很多，但我仍然很难过。

我尝试了一个能够处理适当负载斜坡的怪物 linux 服务器，大概每秒有数千个连接。现在，如果我检查默认的 listen() 队列：

这根本不是实际的队列大小。我怀疑它可能是一个遗产，实际大小是由这个给出的：

但是，man tcp后者表示等待来自客户端的 ACK 连接，这与尚未接受的连接总数不同，这就是 listen() backlog 的含义。

所以我的问题是如何增加listen() backlog以及如何获取/设置它的上限（在内核重新编译之前）？

Team Foundation Service 的文档说我应该能够使用左侧的菜单选项添加积压项目，如下所示：

但是在我的帐户中，我没有得到这个选项：

如何启用在 TFS 中添加积压项目的功能？

我有一些故事计划用于 sprint，但由于突然的变化/优先级，它们现在已经被取消了当前版本的范围，并且可能会在以后的某个版本中使用。由于我们目前对这些故事没有任何可见性，我们希望将它们移至积压并给予低优先级。- 有没有办法在集会中做到这一点，或者我必须为那些积压的人创建新故事并删除当前的故事？- 我可以创建一个规则（如通知规则），创建积压故事的报告，并每月通过电子邮件将其发送给 DL。

我最近一直在研究一些服务器-客户端代码，我发现了一个非常令人困惑的问题。我server在端口上监听并设置backlog = 2，我的客户端创建 5 个线程到connect.

在man中，我注意到

这意味着我的客户端连接将失败或稍后重试。

但是当我的客户端运行时，它只是收到一个 SIGPIPE 信号并失败了。

所以我运行sudo tcpdump -ilo0 port 10000并得到结果：

summertekiMacBook-Pro：选择 Summer$ sudo tcpdump -ilo0 端口 10000

tcpdump：详细输出被抑制，使用 -v 或 -vv 进行完整的协议解码监听 lo0，链接类型 NULL（BSD 环回），捕获大小 65535 字节

10:29:16.396240 IP localhost.56347 > localhost.ndmp: 标志 [S], seq 3366561899, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK,eol],长度 0

10:29:16.396241 IP localhost.56349 > localhost.ndmp: Flags [S], seq 902832276, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK,eol],长度 0

10:29:16.396242 IP localhost.56351 > localhost.ndmp: 标志 [S], seq 1956535575, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK,eol],长度 0

10:29:16.396244 IP localhost.56348 > localhost.ndmp: Flags [S], seq 2161003109, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK,eol],长度 0

10:29:16.396246 IP localhost.56350 > localhost.ndmp: 标志 [S], seq 1318035540, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 0,sackOK,eol],长度 0

10:29:16.396296 IP localhost.ndmp > localhost.56347: 标志 [S.], seq 2871094527, ack 3366561900, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158872 ,eol]，长度为 0

10:29:16.396307 IP localhost.ndmp > localhost.56351: 标志 [S.], seq 3931313020, ack 1956535576, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158872 ,eol]，长度为 0

10:29:16.396332 IP localhost.ndmp > localhost.56349: 标志 [S.], seq 3467781056, ack 902832277, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158772, ,eol]，长度为 0

10:29:16.396349 IP localhost.ndmp > localhost.56348: 标志 [S.], seq 2666080832, ack 2161003110, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158872 ,eol]，长度为 0

10:29:16.396366 IP localhost.ndmp > localhost.56350: 标志 [S.], seq 2467582351, ack 1318035541, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 396158772 ecr 396158872 ,eol]，长度为 0

10:29:16.396375 IP localhost.56347 > localhost.ndmp: 标志 [.], ack 1, win 9186, 选项 [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396381 IP localhost.56351 > localhost.ndmp: 标志 [.], ack 1, win 9186, 选项 [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396386 IP localhost.56349 > localhost.ndmp: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396391 IP localhost.56348 > localhost.ndmp: 标志 [.], ack 1, win 9186, 选项 [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396398 IP localhost.56350 > localhost.ndmp: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0

10:29:16.396408 IP localhost.ndmp > localhost.56347: 标志 [R], seq 2871094528, win 0, length 0

10:29:16.396413 IP localhost.ndmp > localhost.56351: 标志 [R], seq 3931313021, win 0, length 0

10:29:16.396419 IP localhost.56347 > localhost.ndmp: 标志 [P.], seq 1:1001, ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 1000

10:29:16.396424 IP localhost.56351 > localhost.ndmp: 标志 [P.], seq 1:1001, ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 1000

10:29:16.396429 IP localhost.ndmp > localhost.56349: 标志 [.], ack 1, win 9186, options [nop,nop,TS val 396158772 ecr 396158772], 长度 0 10:29:16.396435 IP localhost.ndmp > localhost.56348：标志 [R]，seq 2666080833，win 0，长度 0

10：29：16.396441 IP localhost.ndmp > localhost.56350：标志 [.]，ack 1，win 9186，选项 [nop，nop，TS val 396158772 ecr 396158772]，长度 0

10:29:16.396454 IP localhost.ndmp > localhost.56347: 标志 [R], seq 2871094528, win 0, length 0

10:29:16.396460 IP localhost.ndmp > localhost.56351: 标志 [R], seq 3931313021, win 0, length 0

从unix 网络编程，connect()将启动3 次握手程序，并在服务器发送syn && ack时返回。

从tcpdump输出中，前 10 行告诉服务器回复 syn & sck 虽然积压为 2。后来，客户端发送最后一次 ack和服务器返回 rst。

在我看来，连接返回值！= -1 表示连接已建立并且客户端能够发送数据。但是上面的日志显示它不是那样工作的。

那么谁能告诉我哪个是正确的？