5

由于APE 的 mod_xsendfile 不能与 CF9 的 jrun_iis6_wildcard.dll 一起使用，我只能使用<cfcontent>. 现在的问题是，如果文件下载很大，或者连接速度很慢，会导致一个CF请求长时间的阻塞。如果没有强制实施硬限制的方法，理论上可以关闭 CF 服务器，因为所有请求都与服务文件相关联。

我尝试在下面进行额外的日志记录/逻辑，<cfcontent file="">但我注意到它们从未被访问和执行。 

<cfcontent file="test.mp3">

<!--- won't reach here --->
<cfdump output="console" var="#now()# download done!">

可以做些什么来避免因处理过多的 cfcontent 请求而导致 CF 崩溃？

更新：好消息！CF10 与 APE 的 mod_xsendfile 一起使用！

4

1 回答 1

0

解决方案 1

考虑到由于无法控制的因素（“卡住”的线程、服务/服务器关闭等），您不太可能拥有 100% 的真实会计，您可以执行以下操作：

如果您只想跟踪总请求数，您可以使用在开始提供文件时增加的应用程序变量。然后，当内容完成后，您会减少计数。但是，您需要小心使用 cflock 以确保此更新不会导致任何问题。

如果您想将此记录到文件中，您可以执行相同的操作，但仍将其包装在 cflock 中，以确保您不会在请求同时读取/写入文件时遇到任何问题。

如果您使用 SQL，您可以创建一个表来表示文件，并为每次提取添加一条记录和适当的信息

  • 文件名
  • 完成为有点是/否字段默认为假
  • 用户/客户信息
  • 开始日期/时间默认为现在，
  • 结束日期/时间默认为空，
  • “正在下载”状态
  • 任何其他信息

使用返回的身份 cfcontent 文件，然后在完成后使用正确的日期/时间和状态“成功”更新具有指定 ID 的表并完成为是。

在 onerror 期间，您可以更新表以反映状态“错误 [相关错误详细信息]”并完成为 1。添加一个全面更新以更改为已完成 = 1 或清除未完成的记录不是一个坏主意可用（可能在应用程序启动期间或一段时间后）

这将允许您查询此表以获取当前待处理的请求总数（以及它们是什么等）

但是，这只解决了长时间运行的请求的问题。

解决方案 2

理想情况下，问题是安全地返回文件内容。根据文件的敏感程度（例如，首选私有但不是世界末日），您可以将它们“复制”到适当的 Web 可访问目录，但使用 UUID 作为名称。因此，假设它是 Secret1.pdf，您将使用 cfdirectory 创建一个目录，然后将文件复制到其中。给你这样的东西：

/files/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx/Secret1.pdf 然后执行重定向到该目录。

然后，您可以设置计划任务或网关或您喜欢的任何方法来清除超过设定小时数的目录。例如，删除目录 xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx 以及 30 分钟后的所有文件。

于 2013-09-02T01:11:41.517 回答