You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that for every Arranger project activated 1 apollo server is instantiated. Moreover, each apollo instance creates at least 2 SIGTERM listeners. Therefore, with as little as 5 projects the number of Event Emitters will exceed the default limit of 10 that node (strongly) suggests not to surpass. While not preventing us at all from using Arranger I believe it may influence some design decisions in a future major version.
Locally, here is the warning I get (I have 7 projects):
(node:204653) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. Use emitter.setMaxListeners() to increase limit
at _addListener (node:events:465:17)
at process.addListener (node:events:487:10)
at ...omitted.../clin-arranger/node_modules/apollo-server-core/dist/ApolloServer.js:191:25
at Array.forEach (<anonymous>)
at new ApolloServerBase (...omitted.../clin-arranger/node_modules/apollo-server-core/dist/ApolloServer.js:175:21)
at new ApolloServer (...omitted.../clin-arranger/node_modules/apollo-server-express/dist/ApolloServer.js:60:9)
at _callee6$ (...omitted.../clin-arranger/node_modules/@arranger/server/dist/startProject.js:425:28)
at tryCatch (...omitted.../clin-arranger/node_modules/regenerator-runtime/runtime.js:63:40)
at Generator.invoke [as _invoke] (...omitted.../clin-arranger/node_modules/regenerator-runtime/runtime.js:294:22)
at Generator.next (...omitted.../clin-arranger/node_modules/regenerator-runtime/runtime.js:119:21)
at asyncGeneratorStep (...omitted.../clin-arranger/node_modules/@arranger/server/dist/startProject.js:47:103)
at _next (...omitted.../clin-arranger/node_modules/@arranger/server/dist/startProject.js:49:194)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
Detailed Description
It needs to be carefully thought of, but I would suggest to find a way to have one apollo server per arranger instance. It remains to be seen but it is probably better to have only one instance rather than multiple ones in the case of Apollo server. It would get rid of the warning that I consider a smell. And maybe (it is a big maybe) it would improve performance. If that's the case then every user would benefit from that change.
Possible Implementation
Allowing for multiple projects proves to be very useful in practice once in while. So Ideally, I would like that feature to stay but maybe it would be best to consider using one project only per arranger instance. If one needs more projects for a single app then multiple Arranger instances could be used. That way Arranger delegates the complexity to the client.
The text was updated successfully, but these errors were encountered:
It seems that for every Arranger project activated 1 apollo server is instantiated. Moreover, each apollo instance creates at least 2 SIGTERM listeners. Therefore, with as little as 5 projects the number of Event Emitters will exceed the default limit of 10 that node (strongly) suggests not to surpass. While not preventing us at all from using Arranger I believe it may influence some design decisions in a future major version.
Locally, here is the warning I get (I have 7 projects):
Detailed Description
It needs to be carefully thought of, but I would suggest to find a way to have one apollo server per arranger instance. It remains to be seen but it is probably better to have only one instance rather than multiple ones in the case of Apollo server. It would get rid of the warning that I consider a smell. And maybe (it is a big maybe) it would improve performance. If that's the case then every user would benefit from that change.
Possible Implementation
Allowing for multiple projects proves to be very useful in practice once in while. So Ideally, I would like that feature to stay but maybe it would be best to consider using one project only per arranger instance. If one needs more projects for a single app then multiple Arranger instances could be used. That way Arranger delegates the complexity to the client.
The text was updated successfully, but these errors were encountered: