ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ API Support » will ImqQueueManager survive from one call to another

Post new topic  Reply to topic
 will ImqQueueManager survive from one call to another « View previous topic :: View next topic » 
Author Message
sebastia
PostPosted: Sun Jun 21, 2015 11:59 pm    Post subject: will ImqQueueManager survive from one call to another Reply with quote

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
View user's profile Send private message Visit poster's website
smdavies99
PostPosted: Mon Jun 22, 2015 12:04 am    Post subject: Reply with quote

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
View user's profile Send private message
sebastia
PostPosted: Mon Jun 22, 2015 12:50 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Mon Jun 22, 2015 4:23 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Mon Jun 22, 2015 4:46 am    Post subject: Reply with quote

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
View user's profile Send private message
sebastia
PostPosted: Mon Jun 22, 2015 6:31 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mqjeff
PostPosted: Mon Jun 22, 2015 7:12 am    Post subject: Reply with quote

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
View user's profile Send private message
sebastia
PostPosted: Mon Jun 22, 2015 1:39 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mqjeff
PostPosted: Tue Jun 23, 2015 6:07 am    Post subject: Reply with quote

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
View user's profile Send private message
sebastia
PostPosted: Tue Jun 23, 2015 6:53 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mqjeff
PostPosted: Tue Jun 23, 2015 6:57 am    Post subject: Reply with quote

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
View user's profile Send private message
sebastia
PostPosted: Tue Jun 23, 2015 7:05 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ API Support » will ImqQueueManager survive from one call to another
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.