[SERVER-3] implement inf. loop protection in spider monkey Created: 09/Apr/09  Updated: 07/Feb/18  Resolved: 27/May/09

Status: Closed
Project: Core Server
Component/s: JavaScript
Affects Version/s: None
Fix Version/s: 0.9.3

Type: Improvement Priority: Minor - P4
Reporter: Eliot Horowitz (Inactive) Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

need to make inf. loop protection configurable.
may hold off on this until decide on javascript impl.



 Comments   
Comment by Githook User [ 07/Feb/18 ]

Author:

{'email': 'i80and@foxquill.com', 'name': 'Andrew Aldridge', 'username': 'i80and'}

Message: Remove duplicate opsmgr-server-3.4 definition
Branch: master
https://github.com/10gen/mms-docs/commit/48a17e249eb5f0c4f8e1f4d0776407e5067a0728

Comment by Eliot Horowitz (Inactive) [ 27/May/09 ]

added 1 minute timeout for $where

Comment by Aaron Staple [ 27/May/09 ]

Also, I did not put in a timeout for $where (since I didn't know what duration would be appropriate) but that can easily be added.

Comment by Aaron Staple [ 27/May/09 ]

Eliot, I implemented as described in my earlier comment. There are a few holes, for example a really long sleep() or a hang related to a network failure will not be caught. Each of these cases could theoretically be handled, however they are not strictly speaking infinite loops so we may not care about them.

Comment by Eliot Horowitz (Inactive) [ 27/May/09 ]

didn't you do this?

if not - just assign back to me.

Comment by Aaron Staple [ 19/May/09 ]

I've added support for timeouts in engine's invoke() and exec() and specified a timeout of 10 minutes for db.eval. What should the timeout be for $where?

The timeouts are implemented using spidermonkey's JS_SetBranchCallback(), which means that long timeouts caused exclusively by native functions will not be caught. (For example, sleep( 20 * 60 * 1000 ).) Also, it looks like sleep() isn't available from db.eval at the moment.

Generated at Thu Feb 08 02:52:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.