strange Labview behavior on server

[NPI Chris]

Hello all I have a very strange problem that I am not sure what category it falls under

When I modify a vi (details below) it runs fine on my development box for hours...the development box runs dual core centrino with windows xp.

When i transfer the same modified VI to my server it will run for about 5 minutes or so and then labview instantaneously closes with no windows or error messages popping up. there are also no error messages when labview is restarted. the server has 8 core xeon processor and is running windows server 2003.

I am wondering if the additional cores is causing a problem related to labview trying to multi-thread the vi using all cores? so when it try's to divide the code and run in parallel it is messing with the vi timing somehow?

The modification to the vi is below:

Unfortunately i cant send the entire vi, but this snippet sits in a wait loop and monitors an open adodb connection, this connection must stay open for very long periods (it is part of a web portal) and the DB will time out the connection at times.

the ado get connection properties vi is monitoring the adodb connection and if the db drops the connection the true statement reestablishes it. The db connection and error outs are wired to a large loop that is monitoring for events related to date time. I would think this wiring should force the two to be run serially but i am not sure...

If this snippet is disabled or deleted from the VI it runs fine

Does anybody out there have any ideas or perhaps know of another reason labview maybe shutting down on its own? and why it would work fine on the "smaller" box but not the server?

Any help would be greatly appreciated

thanks Chris

[Grampa_of_Oliva_n_Eden]

Hello all I have a very strange problem that I am not sure what category it falls under

When I modify a vi (details below) it runs fine on my development box for hours...the development box runs dual core centrino with windows xp.

When i transfer the same modified VI to my server it will run for about 5 minutes or so and then labview instantaneously closes with no windows or error messages popping up. there are also no error messages when labview is restarted. the server has 8 core xeon processor and is running windows server 2003.

I am wondering if the additional cores is causing a problem related to labview trying to multi-thread the vi using all cores? so when it try's to divide the code and run in parallel it is messing with the vi timing somehow?

The modification to the vi is below:

Unfortunately i cant send the entire vi, but this snippet sits in a wait loop and monitors an open adodb connection, this connection must stay open for very long periods (it is part of a web portal) and the DB will time out the connection at times.

the ado get connection properties vi is monitoring the adodb connection and if the db drops the connection the true statement reestablishes it. The db connection and error outs are wired to a large loop that is monitoring for events related to date time. I would think this wiring should force the two to be run serially but i am not sure...

If this snippet is disabled or deleted from the VI it runs fine

Does anybody out there have any ideas or perhaps know of another reason labview maybe shutting down on its own? and why it would work fine on the "smaller" box but not the server?

Any help would be greatly appreciated

thanks Chris

With the limited data I can only guess that the Global holding the reference is suffering from a race condition.

Ben

[NPI Chris]

Ben,

thanks for the quick reply, and that makes sense, but debugging this would be a new area for me, any tips on how i could determine if it is? and how to fix it? (or can you point me to some documentation that may help?)

thanks again Chris

[Grampa_of_Oliva_n_Eden]

Ben,

thanks for the quick reply, and that makes sense, but debugging this would be a new area for me, any tips on how i could determine if it is? and how to fix it? (or can you point me to some documentation that may help?)

thanks again Chris

Trouble shooting intermitant problem is not easy particularly if I can't see the code (not implying I want to ).

As I wrote above I was just guessing at it being a race condition since globals are wonderful for demonstrating them.

The best I can do now is (and it will sound drastic) recomend you wrap all of the functionality associated with that reference in an Action Engine with an approriate set of actions so that the the reference never leaves the AE but is used exclusitvely in the AE.

Here is the Nugget I wrote on AE's if you are curious.

http://forums.ni.com/ni/board/message?board.id=170&message.id=240328#M240328

Ben

[Ton Plomp]

What if you don't close the old DB connection?

Still a crash?

If not you'll have to deal with the memory leak (2 bytes per 5 minutes.)

Do you really need the global? It seems you have a 'get connection' that should be able to do the same as the global.

Ton

[NPI Chris]

Ben thank you an excellent nugget of which I am still trying to digest all of it, but I think the concept will actually help me in some other apps as well

Ton, Thanks, I will try that, although this solution was an attempt to get of af a worse memory leak from our first attempt at keeping the connection alive. Unfortunatly i do need to keep the global as it is being populated in order for a multitude of other VI's in the portal system to use. the get connection that continues on is being used internally in the vi as well.

thanks again, I will let you know how it goes when I get all of the proposals tested....

Chris

[David Boyd]

Is Windows server 2003 a supported target for LabVIEW 2009? I know that it specifically WAS NOT under prior versions, though over the years there have been reports of folks running LV apps on WS2003. I'm just asking to point out that you may not be able to get support from NI for any issues you have. Whether this is an issue for you, I couldn't say.

Along other lines, have you checked the Windows event log on the target? Perhaps there is an application error event getting recorded which could suggest what's going on.

Good luck!

Dave

[Mark Yedinak]

Ben thank you an excellent nugget of which I am still trying to digest all of it, but I think the concept will actually help me in some other apps as well

Ton, Thanks, I will try that, although this solution was an attempt to get of af a worse memory leak from our first attempt at keeping the connection alive. Unfortunatly i do need to keep the global as it is being populated in order for a multitude of other VI's in the portal system to use. the get connection that continues on is being used internally in the vi as well.

thanks again, I will let you know how it goes when I get all of the proposals tested....

Chris

I know that you probably don't want to hear this but as Ben suggested I would seriously consider removing the globals from your application. There are much better and safer ways to share information between parallel tasks. These include action engines, queues and notifiers.