| Author |
Message
|
| sebastia |
 Posted: Sun Jun 21, 2015 11:59 pm Post subject: will ImqQueueManager survive from one call to another |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi.
I am calling MQ C++ code from node.js and have connected to queue manager.
node.js has received control at mq operation start and again at operation end.
The connect() operation has filled up a "ImqQueueManager" var in C++, and control now is back at JavaScript. Maybe hours can pass before next async operation comes to C++ code, probably to do a open() operation.
My question is : will the "ImqQueueManager" var still be valid when this second mq operation comes to C++ ?
Sebastian. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Mon Jun 22, 2015 12:04 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
What do you think happens?
does the Operating system create a new process/threadwhen calling the C++ Application?
does that thread survive the return to Javascript?
So what is it then?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Jun 22, 2015 12:50 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I think my C++ code goes into memory when required (yes, I'd say a thread is created), a memory space is allocated for "qmgr" object, the MQ API is called, that finishes well.
Return code goes to JavaScript and control also.
I'd say the thread shll survive the return to JavaScript ... for a while.
But I dont know what shall happen 10 minutes later.
And I would like to hear some opinions before start coding - maybe I shall have no future, jejeje
If thread goes out of memory, then the C++ qmgr object shall lose all its values, so no good to try to reuse it on next API call, dont you think ?
In fact, my problem is that I can not pass such an object from C++ to JavaScript, which should be the way to go.
Or at least I dont know how to do it, which is a bit different. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 22, 2015 4:23 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I'd look at finding if there is such a thing as a javascript to native interface.
At which point you do not want to return just the return code to js you want to return the object (i.e. qmgr) which would include the handle and other fields... As well you'd need to consider the scope of your object in js. Is it the call, the application? etc... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 22, 2015 4:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| I'd look at finding if there is such a thing as a javascript to native interface. |
I think he's spent a good amount of time trying just that.
| fjb_saper wrote: |
| At which point you do not want to return just the return code to js you want to return the object (i.e. qmgr) which would include the handle and other fields... As well you'd need to consider the scope of your object in js. Is it the call, the application? etc... |
It's a question of what the thread does. If the C++ thread goes away, and the MQ handle was declared inside the thread, or worse if the entire C++ context goes away, then the handle is invalid and you'll need to reconnect.
If the C++ context doesn't go away, you should be able to implement a connection pool, and reuse those as threads get activated. As long as they're all connected to the same qmgr, you're good to go.
You might also want to create an object pool - mqopens - as well. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Jun 22, 2015 6:31 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr Saper - yes, please have a look. Should you find it, you'd change my life for the next 3-6 months.
Return the whole object to Javascript, that does not like binary values : not easy (but I think it is the only way)
The scope of the object : as long as JavaScript requires.
My conclusion is : as JavaScript can receive request from multiple (web) clients, then C++ must be able to receive the connect() handle from node.js in order to open() a queue - do we agree ?
That changes all, a a lot. Have to sit and think.
Thanks for your comments, coleagues.
I appreciate your collaboration.
Sebastian. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 22, 2015 7:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sebastia wrote: |
| The scope of the object : as long as JavaScript requires. |
So if you can establish this in your startup and ensure it doesn't go away until app end, you should be fine.
| sebastia wrote: |
| My conclusion is : as JavaScript can receive request from multiple (web) clients, then C++ must be able to receive the connect() handle from node.js in order to open() a queue - do we agree ? |
Again, I think you can get away with at least a connection pool - every time JS asks you to connect, pull one from the pool - if there's room for more, maybe create a new one. SO JS could simply pass the name of the qmgr, or the conninfo (not the MQCONN handle), and the c code could use this to lookup from the connection pool.
There might already be basic connection pooling built into the C++ apis.
Likewise, you could do the same with queue names and queue handles. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Jun 22, 2015 1:39 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Good evening.
To tell you the truth, I've never liked the "connection pool" concept.
But in this environment I think it is not possible.
As I see the JavaScript application, there can be multiple web clients requesting connections to lots of diferent queue managers.
But maybe this project shall be less ambitious at the beginning and try to connect one browser to one (local) queue manager.
I think the main problem here is that the C++ can go out of memory, so all info held there would be lost.
So, it has to be node.js that has to keep the MQ info. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 23, 2015 6:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I think if the C++ code goes out of context, so does the MQCONN handles.
So even passing them back to node.js doesn't help, because they might blow up when you try and reuse them. I mean, sure, you can detect the error for that, and then reconnect. But that assumes you also have the information needed to reconnect to the same qm - and then reopen the same queue objects.
Instead of a connection pool, you could use a C++ thread pool, with each thread holding a connection to a queue manager -and then the node.js calls get passed to a thread that belongs to the right qm. Then when the C++ goes out of context and comes back, you can then reconnect and rebuild threads.
Will the node.js be running in the browsers, or in a standalone separate container? If it's running in the browsers, you have to worry about not creating lots of short-lived connections. If it's running in a standalone instance, you're really better off building a pool of some kind - again to avoid making lots of short-lived connections. |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Jun 23, 2015 6:53 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
node.js shall run standalone, on a server.
And I also thought on keeping a thread alive until connection is closed, but this gentleman told me there in no way to talk from one thread to v8 :
| Quote: |
| Calling callback from a different thread is not an options, v8 doesn't allow that. |
>>> http://stackoverflow.com/questions/30862736/node-js-and-c-c-integration-how-to-properly-implement-callbacks
Your phrase "passing them back to node.js doesn't help, because they might blow up when you try and reuse them" ... is worrying me a lot.
Enjoy St John's Eve - and let the problems and doubts fly away in the smoke of old fashioned furniture burning on the sea shore ... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 23, 2015 6:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ handles are in memory objects, so the C++ memory goes away, so do the objects.
I don't know how node.js handles 'global' variables, or if it does. But, again, that's where a connection pool would go. (maybe a singleton of some sort?)
I'd rather burn things other than my lovely furniture, but have fun with your pyrotic activities anyway! |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Jun 23, 2015 7:05 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
yes, C++ memory going away IS A PROBLEM.
if you dont burn (forget, remove) old stuff, it lives with you forever, goes around in your backpack
the basic idea is : if new items have to come, you have to make space for that, am I right ?
Yes, in Valencia we do crazy things with fire and powder, somebody even calls it "funny", jejeje |
|
| Back to top |
|
|
|
|
