Reason for mutex_unlock() Error ?
Moderators: chulett, rschirm, roy
Reason for mutex_unlock() Error ?
Hi !
I am using a funnel stage that combines data from two source. Now , the problem is that from one of the source (Transformer Stage) , I am getting the following error:
ds_ipcflush() - Error in mutex_unlock() - Not owner
Please advice me the reson for the particular error.
Thanks
Nitin
I am using a funnel stage that combines data from two source. Now , the problem is that from one of the source (Transformer Stage) , I am getting the following error:
ds_ipcflush() - Error in mutex_unlock() - Not owner
Please advice me the reson for the particular error.
Thanks
Nitin
Re: Reason for mutex_unlock() Error ?
Hi,
I think it is better you check with your DBA once. And can explain what exactly you are doing after the funnel stage(loading the data into any table or etc..).
I think it is better you check with your DBA once. And can explain what exactly you are doing after the funnel stage(loading the data into any table or etc..).
Re: Reason for mutex_unlock() Error ?
Hi Meena,meena wrote:Hi,
I think it is better you check with your DBA once. And can explain what exactly you are doing after the funnel stage(loading the data into any table or etc..).
Thanks for the reply !
Well after the funnel stage'
Funnel stage -->TX--->Seq stage (target )
at the TX , performing lookups and updating tables in Oracle database, then the output goes into the seq stage (flat file)
Thanks ,
Nitin
See I am doing a conversion from server to parallel , the job runs perfectly fine with same parameters in server.thumsup9 wrote:Do you have enough space on the disk where you are writing your target file.
Therefore, space wise target is fine. I am creating this job in parallel just to speed up the process.
let me know where am I wrong !
what can be done to resolve that error
see I am working in parallel extender, there is no IPC stage in itthumsup9 wrote:Do you have any other stages like IPC or Link Partioner in your job design. Once had a similar problem and removed the IPC and it performed OK.
Another option I found in the forum is to check inter process under Enable row buffer option and increase the time out-say 60sec.
HTH
Re: Reason for mutex_unlock() Error ?
This message is unfortunately not particularly help. When one side of the pipe terminates and the other side can no longer communicate you get this error by the surviving process. So this is just reporting that your job has terminated and isn't itself the error. Do you have any other messages in your log that could be used to track down the error? Have you tried a reset to see if you get any additional information?nitin376 wrote:...ds_ipcflush() - Error in mutex_unlock() - Not owner...
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Sorry Nitin, had a big fat lunch!! As ArndW suggested, do you have any other information in the log..nitin376 wrote:see I am working in parallel extender, there is no IPC stage in itthumsup9 wrote:Do you have any other stages like IPC or Link Partioner in your job design. Once had a similar problem and removed the IPC and it performed OK.
Another option I found in the forum is to check inter process under Enable row buffer option and increase the time out-say 60sec.
HTH
Sorry Nitin, had a big fat lunch!! As ArndW suggested, do you have any other information in the log..nitin376 wrote:see I am working in parallel extender, there is no IPC stage in itthumsup9 wrote:Do you have any other stages like IPC or Link Partioner in your job design. Once had a similar problem and removed the IPC and it performed OK.
Another option I found in the forum is to check inter process under Enable row buffer option and increase the time out-say 60sec.
HTH
Re: Reason for mutex_unlock() Error ?
The Job desc is as follows:ArndW wrote:This message is unfortunately not particularly help. When one side of the pipe terminates and the other side can no longer communicate you get this error by the surviving process. So this is just reporting that your job has terminated and isn't itself the error. Do you have any other messages in your log that could be used to track down the error? Have you tried a reset to see if you get any additional information?nitin376 wrote:...ds_ipcflush() - Error in mutex_unlock() - Not owner...
seq stage -----> TX------>Funnel<-----TX------Oracle EE
.........................................|
.........................................|
.........................................V
........................................TX stage
the error details are as follows :
ETRValidateShip.#1.X_CURRENTSHIP.l_CurrentShipList_SeqOut-Input.l_CurrentShipList_SeqOut: ds_ipcgetnext - timeout waiting for mutex
Attempting to Cleanup after ABORT raised in stage ETRValidateShip(X_CURRENTSHIP).#1.X_CURRENTSHIP
ETRValidateShip.#0.X_CURRENTSHIP.l_CurrentShipList_SeqOut-Input.l_CurrentShipList_SeqOut: ds_ipcgetnext - timeout waiting for mutex
Attempting to Cleanup after ABORT raised in stage ETRValidateShip(X_CURRENTSHIP).#0.X_CURRENTSHIP
please advise me !
Nitin
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Inter-process communication is automatically used in parallel jobs - indeed there is no IPC stage. Timeouts in IPC most usually result from overloaded systems or, in MPP configurations, overloaded or damaged networks.
Access to resources is controlled by semaphores, which are implemented differently on different kinds of UNIX. On your operating system semaphores are implemented as mutual exclusion (mutex) locks.
Read the error message carefully, and answer these questions based on what you read there.
1. What is the job name?
2. Was this job running in multi-instance mode at the time?
3. What is the stage name in which the error occurred?
4. What is the name of the link from which the error was reported?
5. What is the purpose of this link in the job?
Inspect your job logs. Do all instances read different source files, or is it possible that two (or more) instances might have been reading the same file? From the "environment variables" entry (second event for the job run), please advise what buffering strategy was being used.
Access to resources is controlled by semaphores, which are implemented differently on different kinds of UNIX. On your operating system semaphores are implemented as mutual exclusion (mutex) locks.
Read the error message carefully, and answer these questions based on what you read there.
1. What is the job name?
2. Was this job running in multi-instance mode at the time?
3. What is the stage name in which the error occurred?
4. What is the name of the link from which the error was reported?
5. What is the purpose of this link in the job?
Inspect your job logs. Do all instances read different source files, or is it possible that two (or more) instances might have been reading the same file? From the "environment variables" entry (second event for the job run), please advise what buffering strategy was being used.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.