Meteor.js Spiderable 和 Iron Router - 生产服务器上的光纤错误

Question

我无法让 Iron Router 和 Spiderable 在我的 Meteor.js 应用程序中很好地协同工作。如果我在本地主机上运行时使用?_escaped_fragment_= 测试一个url，它一切正常，但是一旦我推送到我们的DigitalOcean 生产服务器，我在尝试相同的事情时不断收到以下错误（查看http://hreglobal.com/?_escaped_fragment_=）：

Error: Meteor code must always run within a Fiber. Try wrapping callbacks that you pass to non-Meteor libraries with Meteor.bindEnvironment.
at Object.Meteor._nodeCodeMustBeInFiber (packages/meteor/dynamics_nodejs.js:9)
at _.extend.get (packages/meteor/dynamics_nodejs.js:21)
at RouteController.lookupOption (packages/iron:router/lib/route_controller.js:66)
at new Controller.extend.constructor (packages/iron:router/lib/route_controller.js:26)
at ctor (packages/iron:core/lib/iron_core.js:88)
at Function.Route.createController (packages/iron:router/lib/route.js:133)
at Function.Router.createController (packages/iron:router/lib/router.js:185)
at Function.Router.dispatch (packages/iron:router/lib/router_server.js:39)
at Object.router (packages/iron:router/lib/router.js:15)
at next (/opt/hre/bundle/programs/server/npm/webapp/node_modules/connect/lib/proto.js:190:15)

这几天一直在寻找原因，开始有点绝望。欢迎大家指点！

Answer 1

以防万一这对将来的任何人有所帮助......

我也遇到了这个问题。我尝试了我能想到的一切以及所有其他论坛建议的一切。

我的解决方案是我的服务器！我有一个带有 AWS EC2 的 t2.nano，并且我已经使用 mup 上传了我的应用程序。

我花了很长时间才意识到这是原因......但如果我只有 2 个应用程序运行一切正常。然后我添加了第三个应用程序，这就是问题发生的时候。我猜这是因为我运行的基本服务器无法为我的应用程序处理 3 个 docker 容器，而无法为 mongo 处理第四个容器。

我在使用 mup 上传我的第三个应用时也总是遇到问题。我猜这可能是问题的一部分。

所以重点是......您的出版物等可能都还可以，但是从服务器本身而不是应用程序获得响应的时间也会对此产生影响。

Answer 2

远程主机上的脚本是否已安装/可访问 phantomjs？

我安装了一个更复杂的爬虫包：

https://atmospherejs.com/jazeee/spiderable-longer-timeout

这向我显示了一条实际的错误消息，而不是无关紧要的 Error: Meteor code must always run within a Fiber.

错误代码似乎是：

spiderable: phantomjs not installed. Download and install from http://phantomjs.org/

事情在之后立即开始工作：

sudo apt-get install phantomjs

Answer 3

这有几个原因：

当这种情况发生在生产环境而不是本地时，这可能意味着包存在缩小问题。要对此进行测试，您可以运行 meteor build --debug 跳过缩小和部署。或者您可以使用 meteor run --production 在本地运行，它将在本地运行并缩小。无论哪种方式都应该告诉你它是否是一个缩小问题。

生产问题但不是本地问题的另一个选项是可蜘蛛的超时问题。增加超时时间看看是否能解决问题可能是值得的。不过我会先尝试缩小。

第三个生产问题而非本地问题与 ROOT_URL 错误有关。这也值得快速检查。确保您的服务器配置使用的 ROOT_URL 可由服务器本身访问。

如果这发生在本地和生产服务器上，这可能是由于发布调用未正确返回 ready() 造成的。这可以通过注释掉错误端点上的订阅来调试，直到找到错误的发布。