| Author |
Message
|
| extrany |
 Posted: Mon Sep 19, 2011 5:57 am Post subject: Flow hanging |
 |
|
Novice
Joined: 01 Sep 2011
Posts: 14
|
Hello All,
We have a big flow. On one stand it is working normally. On another (Broker 6.1.0.9, toolkit 6.1.0.9 to creating bars) it's hanging while entering a compute node. No information about this in user trace, no information in odbc trace. In debug before compute node (that is located in a subflow) after choosing "Step into source" we have nothing. Flow can't read from input queue. After some time (about 360secs ++) EG stopped with error of timeout with no information about reasons of hanging flow in logs. No useful information in system log.
OS is AIX. In compute node some mapping and 1 DB select to Environment.
Any ideas?
P.S. Tried to increase MQSI_THREAD_STACK_SIZE, no help. Tried to create new EG with only this flow in it, no help. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Mon Sep 19, 2011 8:06 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
So what goes on inside this mysterious compute node?
Anything Special?
Any possible loops?
We are sitting here waiting to be enthralled...
_________________
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 |
|
|
| extrany |
| Posted: Mon Sep 19, 2011 10:24 am Post subject: |
|
|
Novice
Joined: 01 Sep 2011
Posts: 14
|
So there is the question - does it matter what is inside compute node? Because flow dropped(hanging) while entering in it (before entering?).
In node - some DECLARE's, some sets, one Select statement (Select * from database.{SCHEMA}.{TABLE} as a where a.xxx = yyy;), then some if and sets - nothing special. No loops! Data source is promoted property.
Maybe some errors with memory/stack in broker? No information about this in logs... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Sep 19, 2011 10:49 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Have you verified that the DSN is working properly?
Broker tries to initiate the DSN connection in a sort of lookahead operation. i.e. have it open before it is needed. From your description it might be this that is failing.
Are you sure that the promoted property is correctly set?
_________________
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 |
|
|
| lancelotlinc |
| Posted: Mon Sep 19, 2011 10:55 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
If you were on WMB v7, to check the viability of an ODBC conx, you could run
| Code: |
| mqsicvp -n <dsn> -u <service_id> -p <password> |
Don't remember if there is an equivalent command in v6. How long you going to keep v6 around?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| extrany |
| Posted: Mon Sep 19, 2011 11:11 am Post subject: |
|
|
Novice
Joined: 01 Sep 2011
Posts: 14
|
| smdavies99 wrote: |
Have you verified that the DSN is working properly?
Broker tries to initiate the DSN connection in a sort of lookahead operation. i.e. have it open before it is needed. From your description it might be this that is failing.
Are you sure that the promoted property is correctly set? |
DSN - will try.
About correct/incorrect property - Broker will throw an exception if properties will incorrect. But i checked, properties are correct.
Before this compute node we have other subflows with DB work, same operations... |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Sep 19, 2011 11:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Check transaction mode property on the Compute node. Should be set to 'Automatic'. Hopefully the rest of your flow Transactionality is set to 'Off'.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| extrany |
| Posted: Tue Sep 20, 2011 1:38 am Post subject: |
|
|
Novice
Joined: 01 Sep 2011
Posts: 14
|
| lancelotlinc wrote: |
| Check transaction mode property on the Compute node. Should be set to 'Automatic'. Hopefully the rest of your flow Transactionality is set to 'Off'. |
On this compute node transaction mode is set to "Automatic". Before and after this node also "Automatic". |
|
| Back to top |
|
|
| extrany |
| Posted: Thu Sep 22, 2011 5:57 am Post subject: |
|
|
Novice
Joined: 01 Sep 2011
Posts: 14
|
Problem solved.
The Select in the compute module was like
'Select * FROM ... WHERE ...'.
Before entering to compute node happened something like DB(AS/400) asked about SQLColumns and didn't find anything good and all hanging.
Bad odbc drivers mb. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 22, 2011 8:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| extrany wrote: |
| Bad odbc drivers mb. |
Not exactly great SQL either. SELECT * requires a lot of addition code to deal with (and indeed identify) the columns being returned.
(Or it can just assume what columns come back and crash 4 years after authorship when a new column is added. Just pulling a theoretical example there).
It also precludes a lot of index and caching use.
Was the flow hanging in the odbc layer or the database?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
