EldoS | Feel safer!

Software components for data protection, secure storage and transfer

One Issue Fixed, Another Issue Introduced

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#2056
Posted: 01/25/2007 10:53:43
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Christopher Zielinski wrote:
What I am saying, is that I apologize for having submitted an issue that I personally did not verify.


Well, I do not care how difficult it may be to believe, but I have verified all my information and can report that the lastest version (v.1.5.7.52) of MsgConnect's multi-casting (/broadcasting) does not work -- on some computers where it used to work with a previous release of MsgConnect (v.1.5.7.49)!

Everything I have written here is true, regardless how difficult it is to believe.

Multi-casting (/broadcasting) works in my development environment. The new MsgConnect version multi-casting does not work on the very same computers in the very same network configuration in our quality assurance department though. I do not care if you say it is impossible, because I have verified that it is happening!

There are only two things that have changed:

1) MsgConnect from v.1.5.7.49 to v.1.5.7.52
2) Previously I always compiled my project with compiler optimizations on, but have turned them off, due to your MsgConnect change history comments.

I guess there is nothing more to say about this, except I really look forward to the fix in a few months, providing the fix does not introduce any new issues.

As for our software solution that uses MsgConnect? My solution is to use your latest release and replace multicasting with round-robin UDP messaging. This is really going to increase network traffic in a busy environment, but should prove to be the most reliable.
#2057
Posted: 01/25/2007 11:29:12
by Eugene Mayevski (EldoS Corp.)

Once again: instead of stating again and again that it doesn't work for you (maybe. Everything is possible) you can spend 5 minutes doing what I described in the previous messages and get the result.

Some time ago you spent months arguing instead of building a sample. The sample then has shown a configuration problem in your code (zero timeout for connection if you remember) which was solved in 5 minutes. Now you have a choice to either argue for some months again or try the above mentioned changes.


Sincerely yours
Eugene Mayevski
#2060
Posted: 01/25/2007 11:57:41
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Eugene Mayevski wrote:
OK, if you don't believe ... CVS contains revisions 1.46 (this one was created in June, 2006) and 1.47 created in October. The only difference between them was implementation of TUDPSocket.Destroy destructor.

You can comment out this destructor (this will lead to UDP socket leakage) and see if this changes anything.


I could not locate "TUDPSocket.Destroy" in the MsgConnect source code. Are you sure that this is the method you want me to comment out for your test?
#2126
Posted: 01/30/2007 17:21:33
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Great news!

After working on this issue/problem at our software quality assurance department's physical site, I now have a much better picture of what is going on.

THE LATEST VERSION OF MSGCONNECT IS THE MOST STABLE RELEASE I HAVE WORKED WITH ! ! !

I am really happy that the UDP port closing issue has been resolved because that issue appears to be related to our software occasionally hanging and MsgConnect utilizing 100% of the CPU.

As for my issue reported here... well our software quality assurance department sent me down the wrong trail by stating that the previous version of our software (that uses a prior release of MsgConnect) worked in the same configuration (when nothing else in our software changed). MY OWN TESTING verified that this statement could not possibly be true right now -- that is, if they were to install that previous build today, it is not possible for it to work (although I am confident that it really did work in the past).

MsgConnect communications appear to fail, simply because they were not being performed. Our application is extremely complex... but the actual reason the client was not getting the messages that we were expecting was due to missing identifiers in a realtime hardware event. What made this so difficult to trace down was the fact that it works in almost all installations and the fact that I could not use Delphi’s Remote Debugger to debug the server process on the computer system where the issue did manifest itself.

I regret any trouble that I may have caused you with this incident, am very happy that I have stuck with MsgConnect through its bugs and my own, and look forward to a smooth future with its use.

Code prior to the MsgConnect broadcast implementation…

if (fDevId = NIL_DEVICE_ID) then Abort;
if (fCallId = NIL_CALL_ID) then Abort;
#4521
Posted: 12/18/2007 10:25:00
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Christopher Zielinski wrote:
Previously we encountered software hanging when we closed MsgConnect communications (prior to version v.1.5.7.50 -- I have not tested/used v.1.5.7.50 or v.1.5.7.51). We just upgraded to v.1.5.7.52 and are very happy to see that this hanging appears to be fixed (possibly because of the information I previously provided regarding it).

Look forward to your kind and prompt reply...


Hello... I just upgraded to "MsgConnect - version 1.5.7.57 - Released June 14, 2007", from "MsgConnect - version 1.5.7.55 - Released February 14, 2007", but had to back out of the upgrade and go back to using the older version ("MsgConnect - version 1.5.7.55 - Released February 14, 2007"), because the latest version causes our software to hang when we close MsgConnect communications (just like it prior to version 1.5.7.50).

Hopefully you have not made too many changes between version 1.5.7.55 and version 1.5.7.57, as I would rather live with the issue you said that you fixed (re: Cancelling of the message when it was sent by the transport could lead to an error in certain rare cases.), but has not been reported by our users, than consider the prospect of having to create sample programs and the such to prove there is a problem in the MsgConnect code again (i.e. the only change I make is to use version 1.5.7.55 and my problem goes away).

With kindest regards, Christopher
#4525
Posted: 12/18/2007 12:04:02
by Eugene Mayevski (EldoS Corp.)

The changes in builds 53-55 are very important and it makes sense to use them.

We did have some hangs on shutdown however they are completely unreproducible. Looks like UDP messages to localhost are blocked or lost on the client systems. If they are, the behavior is exactly as described.

I've moved your report to HelpDesk cause there are some private things to check/discuss there.


Sincerely yours
Eugene Mayevski
#4528
Posted: 12/18/2007 13:56:34
by Christopher Zielinski (Basic support level)
Joined: 04/16/2006
Posts: 28

Quote
Eugene Mayevski wrote:
The changes in builds 53-55 are very important and it makes sense to use them.

We did have some hangs on shutdown however they are completely unreproducible. Looks like UDP messages to localhost are blocked or lost on the client systems. If they are, the behavior is exactly as described.

I've moved your report to HelpDesk cause there are some private things to check/discuss there.


To clarify... so far, I have not had any problems reported with my software that uses:

"MsgConnect - version 1.5.7.55 - Released February 14, 2007"

That release has worked really well for our purposes. I will now try the tests you emailed me about... and I am very hopeful that it will not have the hanging issue I have when I use 1.5.7.57.

With kindest regards, Christopher
#4529
Posted: 12/18/2007 14:41:45
by Eugene Mayevski (EldoS Corp.)

So it must be just one change that (possibly) has broken the things. This probably explains what's wrong. The cleanup procedure, which takes place during shutdown, causes a deadlock somewhere. Deadlocks are the most hard to trace problem in MsgConnect. While they are eliminated, one change can cause the hard to track deadlock in some circumstance. But at least now I know what to search for.


Sincerely yours
Eugene Mayevski
Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.

Reply

Statistics

Topic viewed 12290 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!