Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Can Develop OPC XML DA C++ client in Visual Studio 2015?

More
25 Jan 2017 13:54 #4889 by support
The ReadMultipleItems is supposed to return when it has finished the work successfully or with failure, OR when it could not finish because of some timeout.

In the current ReadMultipleItems implementation, there is at least one timeout that is set to 100 seconds and cannot be changed. This implies that before these 100 seconds elapse, one cannot decide whether the method has (incorrectly) blocked or not.

Please Log in or Create an account to join the conversation.

More
25 Jan 2017 11:08 #4888 by Vasanth
Hi,

Does that mean ReadMultipleItems function should return in 100 secs? if 100 secs are elapsed than it wont return?

Thanks

Please Log in or Create an account to join the conversation.

More
21 Jan 2017 16:39 #4812 by support
Here is also one more observation from the developer:

There is a SOAP timeout that equals to 100 seconds and cannot be changed currently. This means that any "hang" detection should only deal with execution times longer than 100 seconds.

Please Log in or Create an account to join the conversation.

More
20 Jan 2017 05:26 #4806 by support
I am afraid that we cannot help your further unless we get a solution in which the problem can be reproduced on our side.

There is also a slight chance that it would also help if you can get the issue reproduced with the sample application we have provided AND you would send us the call stacks, but you have earlier written that you cannot do that.

Please Log in or Create an account to join the conversation.

More
20 Jan 2017 05:16 #4805 by Vasanth
Hi,

I do not understand why you are not getting my point. I said clearly this TerminateThread is introduced to resolve hang issue only. Please look at my below commented code, Whatever call stack I sent you thats before introducing TerminateThread logic.

I really do not have time and I am not blaming anybody. I wanted to have a solution/workaround to address this issue. From my side I have tried lot of workaround/solution but nothing is helped till now, unless I get source code of SDK's I can't fix this issue.

Please let me know if its solvable or not, because I cant hold the issue for long time.

Thanks for understanding.

try
{
hThread = CreateThread(NULL, 0, threadAysncOpcXmlDa, &(ptrAsyncSetOpcXmlDa1), 0, &dwThreadId);
WaitForSingleObject(hThread, 40000);
//TerminateThread(hThread, 0);
GetExitCodeThread(hThread, &dwThreadId1);
ExitThread(dwThreadId1);
CloseHandle(hThread);
}
catch(...)
{
CString strFormat;
strFormat.Format("DACSystemThreadGenerator: threadSecScanTagDataOpcXmlDa: Thread Generation/Termination failed.");
DACLogger::Functions::Log(strFormat);
strFormat.Empty();
}
//printf("group %s is ended\n", strGroupName);
//BOOL readFailedStatus = ptrOpcXmlDaClient->readOpcXmlDaTagData(ptrScansetOpcXmlDa->strUrlString, ptrScansetOpcXmlDa->itemNamesCol, strGroupName, &client);

//if (!readFailedStatus)
//{
// DACSystemThreadGenerator::Functions::setThreadOPCXMLDAStopEvent();
// //printf("inside stop : %d", readFailedStatus);
//}

Please Log in or Create an account to join the conversation.

More
19 Jan 2017 14:48 #4797 by support
Is you have already learned, calling TerminateThread does not resolve the hang issue anyway, AND it creates more issues in itself. And one of these issues is that it makes it impossible to troubleshooting the "hang" you claim.

So, remove the TerminateThread from your program. Then, run the test again, and if/when it blocks, capture the call stacks. Those that we have so far are unusable because of your use of TerminateThread in the program.

Please Log in or Create an account to join the conversation.

More
19 Jan 2017 10:51 #4795 by Vasanth
Hi,

Its possible to give some time interval for ReadMultipleItems function or callback ?

Something like below,

ReadMultipleItems(&pArgumentsArray, dwMilliseconds), If possible for you to share the source code?
We can do our required changes? Please let us know ur input.

Please Log in or Create an account to join the conversation.

More
19 Jan 2017 09:54 #4793 by Vasanth
Okay, Thanks for the update.

Therefore, For disposing I am gonna use below lines,

ClientPtr->UnsubscribeAllItems();
ClientPtr->Release();

I do understand about TerminateThread but I don't not have any other option. Initially I was not using TerminateThread function. After the hung issue I was forced to used that, as you know the control is not returning at all from ReadMultipleItems function. FYI, TerminateThread function is used after hung issue only.

If required I can remove TerminateThread function if ReadMultipleItems function does not hung. Please let me know if you have any other solution to avoid this hung issue.

Thanks

Please Log in or Create an account to join the conversation.

More
19 Jan 2017 08:21 #4791 by support
Regarding the "disposing of" an interface pointer to IEasyDAClient: Yes, it is proper to call UnsubscribeAllItems first, if you are subscribed to anything (if you are not, then it is not necessary). And, according to general COM rules, the code needs to call IUnknown::Release() the same number of times AddRef() has been called on the same interface. With your usage of the smart pointers (wrappers) in C++ code, this normally transforms to calling ClientPtr->Release().

I have received your source code.

Unfortunately, the code contains a call to TerminateThread. This is bad. See msdn.microsoft.com/en-us/library/windows/desktop/ms686717(v=vs.85).aspx . There are many problems with it, but here specifically, (quote from the Microsoft doc):

•If the target thread owns a critical section, the critical section will not be released.

This means that if you terminate a thread that is doing something and has acquired some locks, from that moment on nothing else in the program will be able too get pass that lock - and it will hang too. This can explain why in the call stack we have received from you, there is a thread that appears to be waiting on some lock for no reason (no other thread is running that owns the lock).

You must not call TerminateThread. Remove all its usages from your program.
The following user(s) said Thank You: Vasanth

Please Log in or Create an account to join the conversation.

More
19 Jan 2017 05:44 #4790 by Vasanth
Hi,

Hope you have received my source code and Please let me know if you need more info.

Thanks

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.070 seconds