1 of 1 people found this helpful
Same issue for me even with Patch002.
I submitted a ticket to BMC support.
ah ok, nice to know.
Ok there you go... I think I found my issue....
Check your flasboard logs.... I had my application password wrongly set for whatever reason.
Now the engine can connect and I'm monitoring if the error comes back as I had other errors relating to wrong table field as well in there.
I checked my arsystem password, it is correct.
in the arfbserver.log is following written:
<main> <FlashServer> <2009-07-15 09:02:03,026> <BMC Remedy Flashboards(R) Server 220.127.116.11
Copyright (c) 1994-2009 BMC Software Inc. All rights reserved.Connecting to arserver=XXXXX tcp=0 rpc=0>
<main> <FlashServer> <2009-07-15 09:02:04,230> <The server has been suspended.>
<FlashScheduler-Worker-0> <FlashServer> <2009-07-15 09:02:04,230> <The server has resumed operations>
i restart the services. but he can't connect or as unknown reason he suspend after connecting.
in this configure, the arflashd.exe service need always 50% cpu!
the stderr.log and stdout.log are clear.
i don't know my issue.
Were you able to resolve the issue?I see 100% CPU usage for me.
I see the error sometime ego
<FlashScheduler-Worker-0> <FlashServer> <2009-09-14 15:22:04,800> <Could not get new alarms information>
ERROR (90): Cannot establish a network connection to the AR System server; Connection refused: connect
at com.bmc.arsys.api.ProxyJRpcBase.a(Unknown Source)
at com.bmc.arsys.api.ProxyJRpcBase.getRpcClient(Unknown Source)
at com.bmc.arsys.api.ProxyJRpc.ARSetSessionConfiguration(Unknown Source)
at com.bmc.arsys.api.Proxy.setProxyProperties(Unknown Source)
at com.bmc.arsys.api.PoolingProxyManager.getProxy(Unknown Source)
at com.bmc.arsys.api.ARServerUser.getListEntry(Unknown Source)
<FlashScheduler-Worker-0> <FlashServer> <2009-09-14 15:22:05,925> <Could not get new variables information>
ERROR (90): Cannot establish a network
Recently I see
<FlashScheduler-Worker-0> <FlashServer> <2009-09-29 14:16:17,371> <The server has resumed operations>
<FlashScheduler-Worker-0> <FlashServer> <2009-09-29 15:18:16,465> <Too much time has elapsed since last collection for variableSLM:SLACompliance:Contracts Approximating the schedule now.>
<FlashScheduler-Worker-0> <FlashServer> <2009-09-29 15:18:16,527> <Too much time has elapsed since last collection for variableSLM:SLACompliance:Contracts Approximating the schedule now.>
this looks like Defect ID SW00342385
check your FB:History form. If there are many many records (probably millions), delete them and restart the flashboard service.
What great timing, thanks Alexis! I have started to look into this the last few days. I had disabled to service since we were not really using any historical FBs but I want to start using them more. We have +11 million records in our FB:History form. Our DB was built and then moved into production years ago. There was a lot of learning/playing with SLA before the db was moved to production. Some of those SLA FBs have been colleting data for a long time.
I see that SW00342385 is was close and is performing as designed. The defect record on the support site doesn't really show much detail. Do you happen to have any more details regarding this defect? Is it a simple as SLA/SLM is creating a ton of records that are not getting archived off and arflashd.exe tries to load all of the records?
the problem's reason is of out of box FB:Variable collects the data very frequently. The default value is 1 minute. After clearing the FB:History form, goto Developer Studio -> Flashboard variables, reset the compliance contracts flashboard variable from the 1 minute default polling to 1 hour or more in SLM:SLACompliance:Contracts. Then you can continue collecting historical data more healthy.
Thanks for sending the FB variable name, I just updated our new ITSM 7.6 environment. Now off to clean out the FB history in the current prod environment...
Here is additional update. The last 7.6 environment I mentioned in January was a test/proof of concept system. I have just built our future production 7.6 system. I installed SLM last Wednesday. Without any sample data or our own data the FB:History form has over 1.6 million records in it already.
(3 row(s) affected)
I pulled a def file of all of the FB variables and by using the Variable System ID (C40000) it looks like SLM:SLACompliance:Contracts is still the problem child. By default it is set to collect every 3 minutes (which is better than 1 minute as before). The problem is there are 689 record created in one minute (one run) every 3 minutes. The Variable pulls data from SLM:SLAComplianceContract_Join. When I query this form no records are returned.
I’ll update this thread as I find out more.
I am starting to think it may have been a glitch causing some kind of loop. My suspicion is that it is some how DST related. Looking deeper the 689 records that "were created in one minute" all had the exact Sample Date time but looking at the status history they had been created over a few days. None of the records had a Sample Date greater than April 2nd but they were being created up until yesterday when I restarted the Remedy services. DST was on April 2 back in 2006 before the USA extended the DST length.
I just deleted the +1 million records and restarted ARS and FB services. So far there is one record every 3 minutes as expected. I'll update the thread if this changes.
The below work-around may help.
1. Delete the old records in the table.
a. take system offline
b. backup db
c. run SQL script to execute truncation on FB:History form. (get customer dba to check the below example
[Get the schema id value from this query]
SELECT * FROM ARSchema Where [name] = 'FB:History'
Uncomment the below sql command i.e. remove --
* if you have backed-up FB:History table.
* if you have schemaid from above script, your script will look like
* TRUNCATE TABLE T148
--TRUNCATE TABLE T<Schema_ID_retrieved_from_above_query>
2. Then in Dev Studio, set the Flashboard Variable SLM:SLACompliance:Contracts Expiration option to Delete (with a timeframe of say 30 days) and change the sampling interval from 3 minutes to a higher value (say 15mins)
In addition to the above we might also would need to truncate the H table. To get ride of the transactional data.
TRUNCATE TABLE H148;