When I run meteor, sometimes I get an error and it hangs on
=> Your application has errors. Waiting for file change.
I think I've let it sit before and it eventually got past that message, but it always takes a long time. What file change is it waiting for? Is it npm or meteor? And is it slow for others, or is it my Koding box being finicky? Can I just stop the process or should I wait?
I don't need help resolving the error that caused this message in this specific instance, just wondering how to handle meteor errors in general when it hangs on this message and curious as to what it means.
Related
When I start my jobs using fast export they sometimes end with an error:
TDWALLETERROR(543): Teradata Wallet error. The helper process is already being traced
When I restart them, they work.
I'm using saved-key protection scheme.
Can someone explain to me why is that error occuring and how to fix it?
Looks like you have a trace activated in one of the scripts, run in the system.
Teradata has a shiffer code that attempts to validate if tracing is running during the wallet invocation - which triggers this error.
I've been trying to terminate my scripts but I've found that I usually lose these logs and I don't know why. Specifically they are the .xml, .log, and .report files that are produced after the running of a script. Is there someway I can ensure that the logs aren't deleted?
Looks like you are pressing CTRL+C Twice, making it force exit from test run. If you press once, it will create logs.
Even with debug enabled for RemoteConfig, I still managed to get the following:
Error fetching remote config values Optional(Error Domain=com.google.remoteconfig.ErrorDomain Code=8002 "(null)"
UserInfo={error_throttled_end_time_seconds=1483110267.054194})
Here is my debug code:
let debug = FIRRemoteConfigSettings(developerModeEnabled: true)
FIRRemoteConfig.remoteConfig().configSettings = debug!
Shouldn't the above prevent throttling?
How long will the throttle error remain in effect?
I've experienced the same error due to throttling. I was calling FIRRemoteConfig.remoteConfig().fetchWithExpirationDuration with an expiry that was less than 60 seconds.
To immediately get around this issue during testing, use an alternative device. The throttling occurs against a particular device. e.g. move from your simulator to a device.
The intention is not to have a single client flooding the server with fetch requests every second. Make sensible use of the caching it offers out of the box and fetch only when necessary.
When you receive this error, plug the value of error_throttled_end_time_seconds into an epoch converter (like this one at https://www.epochconverter.com) and it will tell you the time when throttling ends. I've tested this myself, and the throttling remains in effect for 1 hour from the first moment you are throttled. So either wait an hour or try some of the other recommendations given here.
UPDATE: Also, if you continue making config requests and receive the throttle error, the expire timeout does not increase (i.e. "you are not further penalized").
The quick and easy hack to get your app running is to delete the application and reinstall it. Firebase identifies your device as new device on reinstalling.
Hope it helps and save your time.
I have the following code that is crashing:
Try
Logger.Warn("do_databind entered.")
Session("AgentId") = AgentId
Session("section") = Section
SectionId.Value = Section.ToString()
Session("dtresponses") = dtresponses
Session("dtlv") = dtlv
lvQuestions.DataSource = dtlv
Logger.Warn("just before databind.")
lvQuestions.DataBind()
Logger.Warn("databind successful. ")
Catch ex As Exception
Logger.Error(ex)
If Not IsNothing(ex.InnerException) Then
Logger.Error(ex.InnerException)
End If
End Try
The coding reaches the "just before databind" message, and then the application aborts. The "databind successful" message is never reached.
The catch loop is never reached because the error message in it is not recorded.
This has been working for months, and just quit working today. I would think it is a server problem.
The listview size at the point of the databind command is only 8 records, and I know the page it generates takes less than 10k total with a number of other blocks it generates.
In the old days, we would say this is probably a heap-stack collision, but I am not sure that terminology applies as well to managed memory in VB.Net. The code that traps the error is probably being overwritten. Other than that, I have no clue as to why it would stop working on our servers overnight.
Has anyone encountered this particular problem before?
UPDATE: The server indicates that it is a stack overflow error in w3wp.exe with error code 0xc00000fd (i.e., stack overflow)
I don't use the databinding or databound events for anything, but it would be an additional diagnostic to see where the memory crash may be occurring.
This app is in testing, so I have extensive error-trapping and comment logging at this point to make sure that the functions are working correctly.
The error does not leave a trace in the program. It is being caught by the server. This makes sense if the error is caused by a stack overflow. It is overwriting the catch code.
UPDATE:
Found the problem.
The program depends on a database, and a change was made to the database that resulted in a recursive procedure that called itself with the same information.
It ran until all the system memory on the server was consumed, and then aborted with a stack overflow error.
I put in diagnostic messages until I finally found it.
The trick here is it was on the staging server, and the database on the development server was not identical, so it worked on the development server the correct way but bombed on the staging server because the database contents were different.
I thought my coding had accounted for the condition that led to the error, but it had not.
Now I know to look for recursive problems if I get an abort in an application that is loaded with try-catch loops and results in no error logging where error logging should exist.
I am currently trying to get search working in my Tridion 2011 installation. I read in another article that I should run the TcmReIndex.exe tool in the Tridion/bin folder to re-index all my sites. So I tried this and it failed with a message box giving the following details
Unable to get list of Publication items.
Unable to Intialize TDSE object.
The wait operation timed out
Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=21054; handshake=35;
The wait operation timed out
A database error occurred while executing Stored Procedure "EDA_TRUSTEES_GETTRUSTEEETOKEN"
I have four fairly large publications (100 000+ items in total) which I am trying to index.
Any ideas?
Whenever I get "Unable to Intialize TDSE object." errors, I typically write a small test script using VBScript, and try running it on the CMS server. Whilst this does not directly solve the problem, it often gives some insight into the issue by logging information in the event viewer. Try creating a test.vbs file as follows and running it:
Set tdse = CreateObject("TDS.TDSE")
tdse.initialize()
msgbox(tdse.User.Description)
Set tdse = Nothing
If it throws any errors, please let me know, and it may help us solve the problem. If it gives you a popup with your user description, then I am completely barking up the wrong tree.
I haven't come to anything conclusive but it seems like my issue may have been a temporary one as it just started working. I did increase all timeouts in Tridion MMC > Timeout Settings by 100 times their amounts but I suspect that this wasn't the issue, when it works the connection is almost instant.
If anyone else has this issue
Restart the computer the content manager is installed on, try again.
Wait an hour or two, try again.
Increase timeouts, try again.
I've run the process a few more times and it seems to be working correctly.