运行连续的Firestore查询时出现Spurious MaxListenersExceededWarning EventEmitter内存泄漏 [英] Spurious MaxListenersExceededWarning EventEmitter memory leak when running consecutive firestore queries

查看:35
本文介绍了运行连续的Firestore查询时出现Spurious MaxListenersExceededWarning EventEmitter内存泄漏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个firebase HTTP函数,该函数依次调用一些firestore操作.如果我多次调用HTTP函数,让每个调用在调用下一个调用之前完成,那么我在firebase函数日志中会收到以下错误:

I have a firebase HTTP function which in turns calls some firestore operations. If I call the HTTP function several times, letting each call finish before calling the next, I get the following error in the firebase functions log:

(node:2) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added. Use emitter.setMaxListeners() to increase limit

firebase函数是一个导入任务,它将数据导入,通过调用firestore查询来检查重复项,如果没有,则通过另一个数据库操作将数据添加到firestore DB.

The firebase function is an import task which takes the data to import, check for duplicates by calling a firestore query, and if there is none, it adds the data to the firestore DB by another DB operation.

这是firebase函数,为简洁起见,删除了部分内容:

Here is the firebase function, with parts removed for brevity:

module.exports = functions.https.onCall(async (obj, context) => {
  // To isolate where the problem is
  const wait = (ms: number) => new Promise(resolve => setTimeout(resolve, ms))
  try {
    const photo = getPhoto(obj)
    // Query to look for duplicates
    const query = db
      .collection(`/Users/${context.auth.uid}/Photos`)
      .where('date', '==', photo.date)
      .where('order', '==', photo.order)
      .limit(1)

    await wait(300)
    log.info('Before query')
    const querySnap = await query.get()
    log.info('After Query')
    await wait(300)

    // And then the rest of the code, removed for brevity
  } catch (error) {
    throw new functions.https.HttpsError('internal', error.message)
  }
})

我在 const querySnap = await query.get()之前和之后插入一个暂停,以表明确实是此调用导致了错误消息.

I inserted a pause before and after the const querySnap = await query.get() to show that it really is this invocation that causes the error message.

我还将Firestore记录器设置为输出其内部记录,以帮助调试问题,方法是:

I also set the firestore logger to output its internal logging to help debug the issue, by doing this:

import * as admin from 'firebase-admin'
admin.initializeApp()
admin.firestore.setLogFunction(log => {
    console.log(log)
})

因此,我得到的更完整的日志输出是:(从下至上阅读)

So the more complete log output I get is this: (read it bottom to top)

12:50:10.087 pm: After Query
12:50:10.087 pm: Firestore (2.3.0) 2019-09-13T19:50:10.087Z RTQ7I [Firestore._initializeStream]: Received stream end
12:50:10.084 pm: Firestore (2.3.0) 2019-09-13T19:50:10.084Z RTQ7I [Firestore._initializeStream]: Releasing stream
12:50:10.084 pm: Firestore (2.3.0) 2019-09-13T19:50:10.084Z RTQ7I [Firestore.readStream]: Received response: {"document":null,"transaction":{"type":"Buffer","data":[]},"readTime":{"seconds":"1568404210","nanos":76771000},"skippedResults":0}
12:50:10.026 pm: (node:2) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added. Use emitter.setMaxListeners() to increase limit
12:50:10.020 pm: Firestore (2.3.0) 2019-09-13T19:50:10.020Z RTQ7I [Firestore.readStream]: Sending request: {"parent":"[redacted]/documents/Users/SpQ3wTsFzofj6wcsF7efRrSMrtV2","structuredQuery":{"from":[{"collectionId":"Photos"}],"where":{"compositeFilter":{"op":"AND","filters":[{"fieldFilter":{"field":{"fieldPath":"date"},"op":"EQUAL","value":{"stringValue":"2019-06-26"}}},{"fieldFilter":{"field":{"fieldPath":"order"},"op":"EQUAL","value":{"integerValue":0}}}]}},"limit":{"value":1}}}
12:50:10.019 pm: Firestore (2.3.0) 2019-09-13T19:50:10.019Z RTQ7I [ClientPool.acquire]: Re-using existing client with 100 remaining operations
12:50:10.012 pm: Before query

有趣的是,我通常以10个批次运行这些导入,我似乎只在10个批次的第一批次中得到错误.如果我随后快速运行更多批次,似乎再也不会出现错误..但是,如果我等待一段时间,它将返回.同样,在批处理中的哪个调用中发生错误也不是一致的.可能是第9个或第2个调用,也可能是其他任何调用.

The interesting thing is that I usually run these imports in batches of 10. I seem to only get the error during the first batch of 10. If I then quickly run more batches, I don't seem to get the error again. But if I wait some time, it returns. Also, it is not consistent in which invocation within a batch the error occurs. It may be the 9th or 2nd or invocation, or any other.

最后,错误不会停止执行.实际上,进口似乎从未失败.但是,我不喜欢在日志中记不清错误!我不能和他们在那里晚上睡觉.:-)

Finally, the error doesn't stop execution. In fact, the imports seem to never fail. But, I don't like have unaccounted for errors in my logs! I won't be able to sleep at night with them there. :-)

感谢您能提供的任何帮助.

I'm grateful for any help you can offer.

推荐答案

我从Firebase支持团队得到了有用的回复.他们告诉我尝试安装最新版本的firebase-admin(将其从8.5.0升级到8.6.0),即使没有安装grpc的解决方法,该问题也得以解决.因此,我认为这应该是正确的答案.

I got a useful response from the Firebase support team. They told me to try to install the latest version of firebase-admin (which upgraded it from 8.5.0 to 8.6.0) and that resolved the issue, even without the workaround of installing grpc. So, I think this should be the correct answer now.

这篇关于运行连续的Firestore查询时出现Spurious MaxListenersExceededWarning EventEmitter内存泄漏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆