Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 18 of 18 total
Thread Client App freezes
Mon, Dec 15 2014 12:29 PMPermanent Link

KyleL

Roy Lambert wrote:

KyleL



As I said, if that happens I'd suspect a race condition somewhere, probably involving transactions. These are very hard to track down.

Roy Lambert
-------------------------
I know it's been awhile but wanted to bring another update on things with follow up questions.

1. We've verified that we are using FastMM in our server application, but the issues still occur.
2. We've update our application to try and reduce likely occurrences of transaction race conditions. We mainly did this by targeting the specific operations around which freezing seemed to most frequently occur, both in the large office dealing with this and smaller ones. Our developer looked over our code and made some changes. These efforts do not appear to have stopped the freezing and they still occur with the same regularity.

Furthermore on this, when considering the notion that our client application might be triggering a race condition I must in response question that were this the case would freezing not occur more frequently from the outset? Taking our applications purpose and design in to consideration the end users essentially are performing the same 8-10 operations in their work flow through the course of the day, and there can be upwards to 50 users doing these workflows at the same time, but the freezing tends to occur only late in the day after all users have been using the application without error up to that point for 6-8 hours. At face value this suggests to me that some fault in the server engine is a more probable cause since the failure never seems to occur more quickly from the outset while our application is being used in full production, which when considering the number of tasks that would be repeated over and over by a large pool of users you would think the fault would be apparent more quickly than it actually is. Taking this in to consideration the next question I think we should ask is what happenings in the server application could gradually accumulate under heavy use through the course of run time and eventually fail 6-8 hours later?

I'll continue to look for ways to track this down on our end, any other thoughts anyone would like to throw out would be appreciated. Thanks!
Mon, Dec 15 2014 4:38 PMPermanent Link

Raul

Team Elevate Team Elevate

On 12/15/2014 12:29 PM, KyleL wrote:

> 2. We've update our application to try and reduce likely occurrences of transaction race conditions. We mainly did this by targeting the specific operations around which freezing seemed to most frequently occur, both in the large office dealing with this and smaller ones. Our developer looked over our code and made some changes. These efforts do not appear to have stopped the freezing and they still occur with the same regularity.

Did you do anything to try to find exactly where the freeze happens and
what the app is doing ? (for example debug logging).


> Furthermore on this, when considering the notion that our client application might be triggering a race condition I must in response question that were this the case would freezing not occur more frequently from the outset?

Not if it's a specific event, sequence of steps or interaction with
multiple clients applications that results in this happening.


> At face value this suggests to me that some fault in the server
engine is a more probable cause since the failure never seems to occur
more quickly from the outset

This is not something you can just reason out. Since you also have to
restart the client apps it could be that that fixes the issue.

There are all kinds of others things that happen during the day that can
contribute to this (like the sleeping PC or app crashing on one PC or
network problems. etc).

You do need to try to get to the root cause : what operation causes
this, at what part of code, is there an error thrown, etc.

You're also using a version of DBISAM that is over 6 years old and you
really should upgrade and make sure issue occurs with newer version.

Raul
Mon, Dec 15 2014 4:51 PMPermanent Link

KyleL

Raul wrote:

On 12/15/2014 12:29 PM, KyleL wrote:

> 2. We've update our application to try and reduce likely occurrences of transaction race conditions. We mainly did this by targeting the specific operations around which freezing seemed to most frequently occur, both in the large office dealing with this and smaller ones. Our developer looked over our code and made some changes. These efforts do not appear to have stopped the freezing and they still occur with the same regularity.

Did you do anything to try to find exactly where the freeze happens and
what the app is doing ? (for example debug logging).


> Furthermore on this, when considering the notion that our client application might be triggering a race condition I must in response question that were this the case would freezing not occur more frequently from the outset?

Not if it's a specific event, sequence of steps or interaction with
multiple clients applications that results in this happening.


> At face value this suggests to me that some fault in the server
engine is a more probable cause since the failure never seems to occur
more quickly from the outset

This is not something you can just reason out. Since you also have to
restart the client apps it could be that that fixes the issue.

There are all kinds of others things that happen during the day that can
contribute to this (like the sleeping PC or app crashing on one PC or
network problems. etc).

You do need to try to get to the root cause : what operation causes
this, at what part of code, is there an error thrown, etc.

You're also using a version of DBISAM that is over 6 years old and you
really should upgrade and make sure issue occurs with newer version.

Raul
--------------------
All valid points, thank you. Should anything else noteworthy be discovered in our troubleshooting of this I will be sure to update/inform this thread accordingly.
Tue, Dec 16 2014 4:07 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Raul


>You're also using a version of DBISAM that is over 6 years old and you
>really should upgrade and make sure issue occurs with newer version.

I agree with everything you've posted apart from this. Throwing a technology change into the mix without solving the problem first is, in my opinion, madness.

Roy Lambert
Tue, Dec 16 2014 4:17 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

KyleL


Rereading your initial post and I'm wondering about this

<<we have a main session thread and a secondary one used for speeding up calculations when they are on the relevant segment of our application>>

Is it possible to move everything into the main thread for a test period?


Roy Lambert
Tue, Dec 16 2014 8:28 AMPermanent Link

Raul

Team Elevate Team Elevate

On 12/16/2014 4:07 AM, Roy Lambert wrote:
> I agree with everything you've posted apart from this. Throwing a technology change into the mix without solving the problem first is, in my opinion, madness.

This is the same dbisam version as before (v4) and just newer build. The
dbisam usage at code level has not changed so likely no code changes are
required.

There have been some big changes underneath like blob handling and more
importantly large number of dbsrvr enhancements (4.29b3 and 4.35) not to
mention various bug fixes and enchancements.

At this point I would consider risk acceptable - especially since OP
goes back 2 months without success yet.

Not to mention that should this require dbisam changes those would
likely only be available in 4.40 build.

Raul
Tue, Dec 16 2014 8:33 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Raul


I have to apologise. For some reason my eyes saw DBISAM but my brain said Delphi. I actually read it several times before making the post and each time it said Delphi. I read it now and it says DBISAM.

My statement should now read I agree with everything you've posted.

Roy Lambert
Tue, Dec 16 2014 9:56 AMPermanent Link

Raul

Team Elevate Team Elevate

On 12/16/2014 8:33 AM, Roy Lambert wrote:
> I have to apologise. For some reason my eyes saw DBISAM but my brain said Delphi. I actually read it several times before making the post and each time it said Delphi. I read it now and it says DBISAM.

No prob. There are times i swear Tim's  NG software adds typos into my
posts as they looked just fine when i read then before posting and then
seeing my own post i go "oops".

Raul
« Previous PagePage 2 of 2
Jump to Page:  1 2
Image