Closed brendon-flanagan closed 8 months ago
I am also hitting the same error , Saw this error after MQRC_NO_SUBS_MATCHED error hit . 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # Fatal error in , line 0 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # Check failed: result.second. 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR # 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR #FailureMessage Object: 0x7ffe4cd50650 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 1: 0xa71261 [node] 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 2: 0x19d3254 V8_Fatal(char const*, ...) [node] 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 3: 0xe5b549 v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptrv8::internal::BackingStore) [node] 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 4: 0xba6a98 v8::ArrayBuffer::GetBackingStore() [node] 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 5: 0x9dba9f node::Buffer::Data(v8::Localv8::Value) [node] 2021-01-11T20:19:56.27+0530 [APP/PROC/WEB/1] ERR 6: 0xad211e
Due to which APP is getting crashed , @ibmmqmet Please look into this .
I've been trying to see if there's anything I can do here. But it does look like there are still issues with either the node engine itself, or with the ref-napi/ffi-napi dependencies. I do at least have a program that reproduces the problems in a node 14 (and 15) environment. One problem with the program is that it relies on having an MQ qmgr environment; not something I can expect people working on these underlying pieces to be familiar with.
There are already issues raised against these other components so I can link to them here:
https://github.com/node-ffi-napi/ref-napi/issues/47 https://github.com/nodejs/node/issues/32463
I'm investigating if there are any alternative approaches to avoid these issues but I'm not very hopeful. I don't know enough about the internals of the engine to try to solve it and offer a fix myself - but I may need to have a go at that. Though anyone else could try to debug it too. Maybe the linked issues can give a starting point.
Thanks
For now I’m now trying a different approach to instead use the java mq libraries instead via the node-java bridge (https://www.npmjs.com/package/java). Early days as only just started looking at, but I got as far as initial connectivity to a qmgr, just to see that node-java bridge was going to work.
For MQ, you could try setting up a docker image that already has everything one needs in it out of the box ? Just a thought.
B.
From: Mark Taylor notifications@github.com Sent: Thursday, 21 January 2021 3:48 AM To: ibm-messaging/mq-mqi-nodejs mq-mqi-nodejs@noreply.github.com Cc: Flanagan, Brendon Brendon.Flanagan@anz.com; Author author@noreply.github.com Subject: Re: [ibm-messaging/mq-mqi-nodejs] Getting error 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long, v8::internal::Isolate) [node] (#108)
I've been trying to see if there's anything I can do here. But it does look like there are still issues with either the node engine itself, or with the ref-napi/ffi-napi dependencies. I do at least have a program that reproduces the problems in a node 14 (and 15) environment. One problem with the program is that it relies on having an MQ qmgr environment; not something I can expect people working on these underlying pieces to be familiar with.
There are already issues raised against these other components so I can link to them here:
node-ffi-napi/ref-napi#47https://github.com/node-ffi-napi/ref-napi/issues/47 nodejs/node#32463https://github.com/nodejs/node/issues/32463
I'm investigating if there are any alternative approaches to avoid these issues but I'm not very hopeful. I don't know enough about the internals of the engine to try to solve it and offer a fix myself - but I may need to have a go at that. Though anyone else could try to debug it too. Maybe the linked issues can give a starting point.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/ibm-messaging/mq-mqi-nodejs/issues/108#issuecomment-763658094, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARV36Z3LFFXB2V6RQVI6HGLS23UIVANCNFSM4VE4NIUA.
"This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."
Of my various testcases that show failures in Node or the ref
prereqs, none of them seem to fail right now with v12.20.1. Some of the failures happened with older levels of v12; some with v14. Unless/until there are fixes found, then that might need to be the recommended level.
https://github.com/node-ffi-napi/ref-napi/pull/55 seems to resolve this - at least my testcase is on iteration 4000 right now instead of crashing when <50. So assuming that gets accepted, once it's available via npm I can update the prereq
@ibmmqmet I see https://github.com/node-ffi-napi/ref-napi/pull/55 PR has been merged and the fix is available in ref-napi@3.0.2
, which will be picked by this module . But i see here https://github.com/node-ffi-napi/node-ffi-napi/blob/master/package.json#L33 that ffi-napi
consumes ref-napi": "^2.0.1
, does this needs to be updated to consume the fix .
Branch ref-napi-fix in this repo pulls in the updated dependencies. That will give people a chance to try it.
You can use "ibmmq":"ibm-messaging/mq-mqi-nodejs#ref-napi-fix"
in package.json
dependencies section.
Assuming it works (and it does work in my test cases that previously failed), I would expect to release a new formal level via npm soon.
In a program I'm writing I have a similar issue if not the same. Connecting and creating/opening up to three queues appears to be uncritical. My program gets its input from a tcp socket, passes it onto one of two permanent queues depending on whether it's a request or a datgram, and picks replies from a dynamic queue to send them back to the tcp client. However, every 20 minutes or so, the tcp connection needs to be reestablished which I tried to handle completely within the connection handler of the server. However, it was not able to handle more than three connections at once, nor did it survive a reconnect attempt from the tcp client. Each time, node crashed with more or less the same error report which clearly points to ffi-napi. Now, I'm forking a new process each time a new tcp connection is established, and it appears to work fine so far. This is feasible since there are not thousands of simultaneous connections to expect. However, even if I kept up this solution, I'd like to work with a "trustworthy" library (not intended to offend soeone ;)), so I'll try this patch and tell you if it works. Otherwise, @ibmmqmet, chapeau and thanks for the great work you did!
I was trying to npm i the modified branch, "ibmmq":"ibm-messaging/mq-mqi-nodejs#ref-napi-fix", but host verification failed (using the standard github host fingerprint), Is there something I need to know?
A quick search via google suggests that either your version of npm needs to be updated, or you need to update ssh keys for github. See for example https://stackoverflow.com/questions/63806821/npm-install-error-host-key-verification-failed
I'd done all this already, but the problem remains. Maybe I’ll have to further investigate. I’m really interested to know if my problems disappear with the new version. I'm just finishing a refactoring of my software so that it can be loaded as a module or run as a child process just by altering a configuration parameter. Anyway, thanks for your quick answer. P.S. Problem identified: My box has a hardware issue - arrgl@x?!!***:(.
@ibmmqmet i started consuming ibmmq@0.9.17 but still i am hitting below error :
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR # Fatal error in , line 0
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR # Check failed: result.second.
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #
2021-03-26T18:01:54.00+0530 [APP/PROC/WEB/0] ERR #FailureMessage Object: 0x7fff49d36d50
2021-03-26T18:01:54.01+0530 [APP/PROC/WEB/0] ERR 1: 0x55920a70b291 [node]
2021-03-26T18:01:54.01+0530 [APP/PROC/WEB/0] ERR 2: 0x55920b87620e V8_Fatal(char const, ...) [node]
2021-03-26T18:01:54.01+0530 [APP/PROC/WEB/0] ERR 3: 0x55920ab7ec7d v8::internal::GlobalBackingStoreRegistry::Register(std::shared_ptr
All I can say is that my test programs started to succeed once I picked up the new version. Did you start with a clean directory where the newer version was installed into? Did you see the gcc compiles run during the installation? Could your enviornment be picking up an older level from somewhere?
Hello Mark,
as I wrote, there are improvements – the process which creates reply messages does not crash anymore when it tries repeatedly to put replies onto a dynamic queue which does not exist any longer. But activities such as opening and closing queues on the same connection frequently make my app still crash. Actually, it receives messages from a TCP connection, puts them onto one of two queues, an asynchronous one and a synchronous one, and collects replies from a dynamically created response queue which it writes back to the TCP socket. Also, after 20 minutes or so, a connection is closed and the corresponding client has to reconnect. To make my tests terminate within a reasonable time frame, I reduced this interval to 30 seconds up to a few minutes. The maximum number of successful reconnections was 5 and appears not to depend on the interval length. I tried with several concurrent TCP connections, and the application crashed after 3 to 6 connections. Starting a child process for each new TCP connection remedies the situation and represents a feasible solution in this case.
I’m using the latest node version and installed the fixed version of ibmmq node.js the installation link to which you indicated in your note. Each time I update I delete the node_modules folder completely before.
Kind regards,
Goetz
Von: Mark Taylor @.> Gesendet: Dienstag, 6. April 2021 14:14 An: ibm-messaging/mq-mqi-nodejs @.> Cc: hellerim @.>; Comment @.> Betreff: Re: [ibm-messaging/mq-mqi-nodejs] Getting error 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long, v8::internal::Isolate) [node] (#108)
All I can say is that my test programs started to succeed once I picked up the new version. Did you start with a clean directory where the newer version was installed into? Did you see the gcc compiles run during the installation? Could your enviornment be picking up an older level from somewhere?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ibm-messaging/mq-mqi-nodejs/issues/108#issuecomment-814070952 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG2K5ERAUO2XCVP2QLWIW3THL3G3ANCNFSM4VE4NIUA . https://github.com/notifications/beacon/AAG2K5D6FR4PX6Y2KUINZPTTHL3G3A5CNFSM4VE4NIUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGCC3ZKA.gif
I suddenly received such error (windows 10, node 14.18, ibmmq 0.9.18). Now updated to 0.9.19, continuing to monitor the problem...
1: 00007FF7BCB3412F napi_wrap+133311
2: 00007FF7BCA5D13F std::basic_ostream<char,std::char_traits
Current versions have stopped usnig the ffi dependencies.
Error is intermittent but frequent.
Sequence is where I'm opening a connection, opening a request queue, opening a reply queue, then closing all in sequence.
Run this about 2 to 3 times and about the 3rd or 4th time it crashes with the below, during either opening the request queue or reply queue..
Full error (but removed path info)
node v14.15.1 npm v6.14.8 ibmmq v0.9.16 ref-napi v3.0.1
Above is in redhat 7
Have also tried in windows svr 2016
And simplified down to just opening a connection then a queue, closing the queue, closing the connection, repeat several times in a row and eventually.