| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Send a Signal from IBM MQ thread |
« View previous topic :: View next topic » |
| Author |
Message
|
| yasaboy |
 Posted: Tue Aug 05, 2014 1:23 am Post subject: |
 |
|
Voyager
Joined: 23 Jun 2014
Posts: 90
|
Hi,
Its really hard to share that. Anyway this is the full scenario that our prototype is trying to do . We have set of threads , and set of queue pairs as (INQ1 , OUTQ1) , (INQ2 , OUTQ2) and so on. IN queues are for system to get inputs and OUT thread for send the responses. Also we have divided the threads as IN threads (get messages from IN_Queues by using MQCB) and OUT thread to PUT the processed messages.
Thread_1 = INQ1 , INQ2 ,INQ3
Thread_2 = INQ4, INQ5
Thread_3 = OUTQ1
Thread_4 = OUTQ2, OUTQ3 so..on
INQ1 is in Thread_1 and the respective OUTQ1 is in Thread_3. Now after getting the message from Thread_1 have to pass it to Thread_3 like wise. There is a Transfer Queue internally defined to pass messages from Thread_1 to Thread_3.
We previously used MQOP_START but inorder to send the messages to our Transfer Queue the thread should be not the one that MQCB creates it should be our internal thread.
So we changed to MQOP_START_WAIT. Then we can add messages to Transfer Queue since a new thread is not created. But this works only to Thread_1 and as soon as the MQOP_START_WAIT fires on Thread_1 it stops right there. Doesn't proceed further to Thread_2.. |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Tue Aug 05, 2014 1:39 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I'm not sure you quite understand what threads are. When you issue a MQOP_START_WAIT then, naturally, the thread issuing the call will 'block'. That's what the wait means. So, there is no concept of "doesn't proceed further to thread 2". Thread 1 will never 'proceed' to thread 2.
I would expect your code to look a little like this......
| Code: |
func(QueueArray[])
{
MQCONN(QMName, &Hcon, &CompCode, &CReason);
for(number of queues in QueueArray[])
{
od,Queuename = QueueArray[index];
MQOPEN(Hcon, &od, O_options, &Hobj, &OpenCode, &Reason);
MQCB(Hcon, MQOP_REGISTER, &cbd, Hobj, &md, &gmo, &CompCode, &Reason);
}
MQCTL(Hcon, [color=red]MQOP_START_WAIT[/color], &ctlo, &CompCode, &Reason);
MQDSIC(&Hcon, &CompCode, &Reason);
}
main()
{
CreateThread(func[INQ1,INQ2,INQ3]);
CreateThread(func[INQ4,INQ5,INQ6]);
CreateThread(func[INQ7,INQ8,INQ9]);
etc.....
WaitForUserInputToEndProgram();
}
|
Here the main thread creates as many threads as you need to process all the queues. Each thread connects to MQ and registers the callbacks. Then issues MQCTL to start processing the queues. Each thread is independant.
Does this make sense ?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| yasaboy |
| Posted: Tue Aug 05, 2014 2:52 am Post subject: |
|
|
Voyager
Joined: 23 Jun 2014
Posts: 90
|
@paul
Thanks for the reply. It explains the fact very clear this is exactly the same code model I am using. But the problem that I have been facing is after execution of Thread_1 it waits for few seconds and generally the system gives a exception as given below. Thread_2 create function doesn't work
| Code: |
================ Thread Instance 1 ================
[New Thread 0x7ffff3d55700 (LWP 593)]
Connecting to Queue -> TEST..INQUEUE1
Connecting to Queue -> TEST..INQUEUE4
Connecting to Queue -> TEST..INQUEUE5
Connecting to Queue -> TEST..INQUEUE7
Connecting to Queue -> TEST..INQUEUE8
Connecting to Queue -> TEST..INQUEUE10
Program received signal SIGTRAP, Trace/breakpoint trap.
0x000000306220d720 in sem_wait () from /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6.x86_64 libaio-0.3.107-10.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64 libgcc-4.4.7-3.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 libstdc++-4.4.7-3.el6.x86_64 libxml2-2.7.6-8.el6_3.4.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 numactl-2.0.7-6.el6.x86_64 openssl-1.0.0-27.el6.x86_64 zlib-1.2.3-29.el6.x86_64 |
The SIGTRAP, Trace/breakpoint trap fires after few seconds of a wait  |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Aug 05, 2014 3:03 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Well, this is the first time, I believe, that you've mentioned that your code is going 'bang', so this changes the whole complexion of the conversation.
The problem is that there is no way that we can tell you why your code is going bang without seeing your code and probably having some more debugging information. Naturally there are an infinite number of reasons why you may experience a crash, these may or may not be related to asynchronous consume.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| yasaboy |
| Posted: Tue Aug 05, 2014 10:11 pm Post subject: |
|
|
Voyager
Joined: 23 Jun 2014
Posts: 90
|
@PaulClarke thank you very much for all the assistance and help sir. Could resolve the issue. Actually it was to done with some code error of mine. It was waiting on a deadlock kind of a scenario.
My main thread which creates child threads was in a wait while the child thread1 responses that it is created to create child thread2 while threaed1 is also in a wait. I didn't knew that I had to send a ack to main app to proceed with thread creation.
Anyway now its all solved and thanks all for trying to help.  |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
