Just implemented the changes you suggested. Works great and I will
continue doing this in the future! The memory
is WAY more stable and I now further understand the point of the
ObjectTemplate now. I did still report this in the issue
tracker, as I hope at least the effect of NewInstance() is
>
> I'm not a V8 maintainer so I can't answer this but to me it seems like
> reasonable behavior. The idea of a template is to share behavior
> across multiple instances.
>
I guess the only reason I would consider it a bug: shouldn't any Javascript
local/persistent be fully cleaned up when
On Mon, May 1, 2017 at 5:20 PM, Brendan Bates wrote:
> I have a question in response to this then. How would you handle a dynamic
> multi-indexed field mapped to a C++ object? Currently we have a root
> ObjectTemplate with an
> indexed property handler that knows it is
Also @Gautham B A we have not figured out a good solution yet - still
reviewing the best way to actually get around this.
On Monday, May 1, 2017 at 11:20:55 AM UTC-4, Brendan Bates wrote:
>
> Seems relevant enough to me if you like efficient programs
>>
>
> Oh I definitely agree it's important,
>
> Seems relevant enough to me if you like efficient programs
>
Oh I definitely agree it's important, just that the topic on hand isn't
necessarily the performance impact but the memory usage. In our case, we
accept the performance
impact for the flexibility of the solution.
It's not an
On Mon, May 1, 2017 at 4:25 PM, Brendan Bates wrote:
>> I don't see an actual memory leak in the code you posted but creating
>> a new ObjectTemplate for every query isn't very efficient.
>
> Just wanted to reply to this to say, that is an irrelevant point to this
>
@Brendan, could you please post how you managed to overcome this issue?
On Monday, 1 May 2017 20:15:09 UTC+5:30, Gautham B A wrote:
>
> Hi Brendan,
>
> I managed to design a work around for this issue. I moved the class that I
> was trying to expose from C++ world to JavaScript -
>
Hi Brendan,
I managed to design a work around for this issue. I moved the class that I
was trying to expose from C++ world to JavaScript -
https://github.com/couchbase/eventing/blob/master/v8_consumer/src/builtin.js
By doing this, whenever a call to "new N1qlQuery()
Hey Gautham B A,
I am currently experiencing a similar issue. I have found that using
NewInstance() causes a slow memory growth/leak in our application. We
aggressively call LowMemoryNotification()
on our scripts, as they are meant to run for a very long time and accept
the performance
Yes, the memory leak in this code isn't visible as it appears.
I observed the memory leak when I ran the "top" command. But when I
commented out the call to "NewInstance()", there wasn't any growth in
memory (which is obvious because there's nothing being created and passed
onto the JS world).
On Tue, Apr 18, 2017 at 9:31 AM, Gautham B A
wrote:
> Thank you Ben.
> Yes, there's a try_catch.HasCaught() before running the script in order to
> prevent the process from exiting.
> Here's the code that will cause the script to run -
> int SendUpdate(std::string
Thank you Ben.
Yes, there's a try_catch.HasCaught() before running the script in order to
prevent the process from exiting.
Here's the code that will cause the script to run -
int SendUpdate(std::string value, std::string meta,
std::string doc_type) {
v8::Locker
On Tue, Apr 18, 2017 at 7:32 AM, Gautham B A
wrote:
> Hi all,
>
> I'm observing a memory leak when the script crashes at runtime. Here the
> JavaScript code (made to crash on purpose by throwing Exception).
> var res = new N1qlQuery('SELECT * FROM `sample`');
> throw
Hi all,
I'm observing a memory leak when the script crashes at runtime. Here the
JavaScript code (made to crash on purpose by throwing Exception).
var res = new N1qlQuery('SELECT * FROM `sample`');
throw 'error'; // purposefully crash.
The corresponding C++ code for N1qlQuery is as follows -
14 matches
Mail list logo