Until we receive the memory upgrade for our server, currently it resides at 2gig we are taking it to 4gig, our prject occasionally shuts down on a thread locked issue. In an effort to make all mgmt aware that something has taken down the FPMI service I was wondering if and how one could use the getSystemFlags or something like that but use it in FSQL. FSQL does not shut down and continues to function properly so if I had someway to monitor the gateway of FPMI in the FSQL program then send an alert message out it would be great. I seem to recall such a thread posted before but could not quite locate it and maybe it might be much easier now with the getSystemFlags.
I’ll putting aside the obvious red flag for a second. If you’re running a stand alone FactoryPMI installation it will be obvious on all client machines if the Gateway is down. The clients will revert to an overlay screen that periodically attempts to reconnect. Eventually the session expires and the FactoryPMI Client reverts to the login screen.
You can create an Action Item in FactorySQL that runs an SQL query against your SQLTags datasource. You can then Alert on that item, which can be configured to send email(s) (text message) and log to the database. Colby, Carl, Travis, Bobby - any ideas on the “best” one to use?
Could you elaborate on the thread locking problem and why a memory upgrade will fix it? Please check the FactoryPMI logs for critical exceptions.
[quote=“mrtweaver”]Until we receive the memory upgrade for our server, currently it resides at 2gig we are taking it to 4gig, our prject occasionally shuts down on a thread locked issue. In an effort to make all mgmt aware that something has taken down the FPMI service I was wondering if and how one could use the getSystemFlags or something like that but use it in FSQL. FSQL does not shut down and continues to function properly so if I had someway to monitor the gateway of FPMI in the FSQL program then send an alert message out it would be great. I seem to recall such a thread posted before but could not quite locate it and maybe it might be much easier now with the getSystemFlags.
I wish I could recall the exact error message. I know it has something to do with threads. Travis do you recall the exact error message? I will also try to get a more updated information from the IT dept. I know that last tuesday I went home ill and our IT staff called and talked to Travis. From what I was told while Travis was doing a gotomeeting the combination of running the Inductive Automation software, the MySQL instance and the Microsoft SQL 2005 instance was eating away at the resources. And when the resources went low this is what caused the thread issue which in turn shut down the FPMI service. Or something close to this explaination. The two recommendations that Travis had given our IT staff was to do away with MySQL and also up the memory on the server from 2 gig to 4 gig. We almost have all the coding changed over so that all queries come from the Microsoft SQL, you see we had it configured from out of the box where all main queries come from Microsoft and the SqlTags and alarms were in the mysql. I had done this because we were still fairly new at SQL 2005 and I knew from a past experience that each query against the 2005 would cause the transaction log to grow and since I did not have admin right to that product to change it so that transaction log would not be a problem I just left some of the items pointing to mysql where i could use admin right to make the changes required. So with that being said now I have changed over almost everything to 2005 so the IT dept can get rid of mysql. But we still have this thread issue and I still question if it could be caused by anyway in the config that the IT dept has on the 2005. The thing that raises a question is they said they have it set up that every 4 hours the transaction log is backed up then erased, the last time they did an erase on the transaction log it caused a lot of issues. So I dont know if it is only because of the memory of the server or if it has any part to do with this transaction log. But in an effort to try to keep things moving forward till they get the memory upgrade I thought why not have the system tell us when it goes down. Which is why i asked the question. My only thing is when FPMI goes down it does not affect FSQL, FSQL keeps right on working. Hope this helps. Have a great day.
I came up with one other question that I hope one can assist with. I know it should be possible but just not sure how to design it.
On a particular screen there is a shift representation number. This is a number of the last shift supervisor to have used the system. The three options are 1, 2, and 3.
Being we have right now 3 work stations what I would like to do is sync up all three stations. Usually only one station is in use at any one time. But if someone on station one changes the shift number from one to two then all workstations will be sync’ed up on the number 2.
Thanks again for all assistance. Have a great day.
java.lang.OutOfMemoryError: unable to create new native thread
This is not a thread “lock”, but rather an inability to create more threads due to running out of memory. Each thread’s “stack” takes up a certain amount of memory, and your SQL server process was taking up about 750mb of memory, not leaving much for the other processes on the machine.
There are lots of solutions to this problem - put the database on its own machine, invest in more memory, tune SQL Server to tell it to use less memory, etc.
On a related note, part of how FactoryPMI uses threads in the clustering stack will be changed in 3.2.0, which should help with this issue as well.