When updating Umbraco to the latest version 7.4.3, we get a Sqlexception when Index rebuilds on app start. The message is: "Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding".
We have a db with extremely much content. The rebuild works if we set supportUnpublished="false". Does anyone recognize this error?
I think you might need to add the 'ConnectionTimeout' property to your connection string. See the post below:
Connection timeout for SQL server
Goodluck
Craig
Related
I have a scheduled task that I want to run every 5 minutes.
I added the url for my method in umbracoSettings.config and the necessary settings but scheduledTasks doesn't seem to be running.
I tried debugging it by calling the url from the browser and I do hit my break point.
I tried checking the logs but there are no errors being recorded. Is this a bug in umbraco? How can I know that the scheduled task is running?
<scheduledTasks>
<!-- add tasks that should be called with an interval (seconds) -->
<task log="true" alias="task1" interval="300" url="http://localhost:43203/umbraco/api/Integration/Init"/>
</scheduledTasks>
I'm using Umbraco 7.5.8
I never had trouble using scheduledTasks in other versions of Umbraco.
The main issue I've seen with scheduled tasks is when the server that's running can't resolve the address in the task. Sometimes a server can be so locked down it can't actually "see" itself, so it can't get to the URL to run it. If this was the case though, you'd normally see some errors in the Umbraco TraceLog file in /App_Data/Logs/.
If your breakpoint isn't getting hit, you could try adding some logging code to the method you're calling and see if that gets written to the Umbraco log files? That way you should be able to tell if it's being hit or not.
Its working now. if you look at umbracoServer table in the database you will see a column isMaster.
The scheduledTasks is only running on the master server.
Socket.io connects to the Java Netty server. If socket.io tries to connect the server while it's down, 404 will be ocurred. So Javascript console says:
http://mylocalhost.com/socket.io/1/?t=1354790544338 - Failed to load resource
After this the socket.io connection dies completely. It won't try to connect again because of that 404...
How should I handle this? I tried to set an interval which would try to connect every five seconds, put the server online, but it won't try to connect because of that error.
After page reload it works normally. Is there a way in socket.io for observing when the server is online again and then connect to it? What could be a proper solution?
I've made sure that the socket.io.js client javscript is loaded correctly, and my understanding of what's happening is this:
socket.io starts handshakes, and socket.socket.connecting is set to true
request to http://mylocalhost.com/socket.io/1/?t=1354790544338 causes 404 because the server is down
this is an error, but socket.socket.connecting remains as true, which causes next reconnect attempts to fail, because it won't try to reconnect if it thinks that it's already trying to reconnect
I've tried calling disconnect() before trying to reconnect, and it sets reconnecting as false, but when there's no connected socket and I call disconnect(), it throws "Cannot call method 'close' of undefined".
What could be a proper solution to get that reconnecting as false, kinda "reset" socket.io to be ready for next connection attempt?
Setting handlers for all of the possible socket.io client errors seemed to fix this problem for me*. That includes:
'connect_error'
'connect_timeout'
'reconnect_error'
'reconnect_failed'
'error'
After a bit of experimenting, the 'error' handler seems to be the important one for preventing the 404 from stopping everything else.
*seemed to fix, because I can't reliably reproduce it in my local test setup. Would be good to know if adding these handlers fixes the problem for anyone else.
The socket.io file it tries to request contains actual script to use in JS. This file is served by your Java server. So when you request this file - it will fail to load, that is why you see 404 error.
Since file is not loaded, anything related to sockets that comes from that file wont be available.
So what you want to try to do, is to catch scenario when script file is not loaded. Check here: load scripts asynchronously
So you have to try to load this script asynchronously, and check on status after load. If it failed or did not responded in time - flush request handle, and request again after some delay.
Once file will be successfully loaded, you can start using JS functions to call connect and so on.
For one of our gerrit projects, while navigating the file differences we get this error:
Application Error
Intraline difference not available due to server error
[Continue]
It doesn't happen for all projects, currently we've detected the error on only one project.
I looked on Google and on the gerrit documentation. Found a reference on their source code, but don't know what causes it and how it can be resolved.
The web page with the error contains a "Continue" button. Once clicked it will take you to the file you selected, but the error is annoying.
Do you know how to fix this?
That is caused while cache the intraline difference of one file, when compared between two commits. The default timeout value is 5 seconds. If the file is huge, and computation takes longer than the timeout, the worker thread is terminated, an error message is shown, and no intraline difference is displayed for the file pair.
A solution could fix this.
Add config in gerrit.conf.
[cache "diff_intraline"]
timeout = 15000 ms # Or other time length as you want.
restart Gerrit service
run SSH command "gerrit flush-caches", using a user with ViewCaches global capability.
ssh -p port userxxx#host gerrit flush-caches
Then it would work.
Cause of the error:
It is a result of Gerrit taking too long to diff the file, and marking the diff in one of its caches as non-available.
The relevant error log is here:
[2012-06-08 11:14:08,547] WARN com.google.gerrit.server.patch.IntraLineLoader : 5000 ms timeout reached for IntraLineDiff in project xxxxxxx on commit 354dd67ad54578cf801d8cda64a4ae8484ebb0b7 for path xxxxxxx.java comparing bf9fbc21520af7bfd0841c8b9f955ca6e215b059..f6b9c7992c12cfdca253acd033966f98f70f3543. Killing IntraLineDiff-6
I'm using CouchDB for my iOS application.
Following is my Application flow,
When my application is launched for the first time it replicates the remote database using xyz:a...#mmm.iriscouch.com/databasename.
if the replication is successful, everything works as expected, but sometimes the replication is not successful. In that case I'm getting the following error with log
1> OTHER: {'EXIT',{error,timeout,#Ref<0.0.0.506>}}
and it doesn't replicate until i remove the application and freshly reinstall the application on the device/simulator.
is there any callback/delegate to handle this?
Somehow when I try synching with empty DB then I never get Error time out, once I have content in DB I get the error!
Also it is hard to replicate on simulator, whereas on iPad occurrence is 90%.
i have placed the sample project in git hub
https://github.com/interactiveblueprints/CouchDBSyncTest (for couchDB username password, please read readme.txt)
this sample code is just modification of PhotoLocations. An example application (https://github.com/couchbaselabs/iOS-Demo-PhotoLocations), But changed as per my requirement.
I have also attached the error logs in
http://dl.dropbox.com/u/35814355/ErrorLog.rtf
Waiting for reply,
Krishna.
I have tried with your sample and updated the "Couchbase.framework" to the latest one, from https://github.com/couchbaselabs/CouchCocoa and now the problem seems to be solved, may be this was a bug in previous version. now it seems the DB tries to restart by itself. and the replication feels more smoother and faster.
We have a situation where our builds have stopped executing in a stable manner.
At a rate of about one every three we receive either TF215096 or TF215097 errors & the Build fails.
If we then restart the Build controller, it works again - until next time.
The errors we get are:
TF215096: An error occurred while connecting to controller vstfs:///Build/Controller/1: There was no endpoint listening at ht*p://XXXX that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
TF215096: An error occurred while connecting to controller XXX - Controller: Could not connect to ht*p://XXX. TCP error code 10061: No connection could be made because the target machine actively refused it 192.168.XXX.XXX:XXX.
TF215097: An error occurred while initializing a build for build definition \XXX: Team Foundation services are not available from server ht*p://XXX. Technical information (for administrator): The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.
TF215097: An error occurred while initializing a build for build definition \YYY: An error occurred while receiving the HTTP response to ht*p://XXX. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
Server logs provide with little info, at least we 've found nothing that helps us resolve the situation. Various searches in the Net were also not productive.
Does anybody had these/similar issues? Any ideas on how/where to look for a resolution?
Thank you very much in advance for any input!
Yeah it does sound like you have some connectivity issues. You can try enabling SOAP tracing on both the build machine and the server (if possible) to see if there is any error. If it still does not give you any new information, contact Microsoft by filing a Connect Bug to get help.
I am not sure if it will help you but I have ran into similar issues with build agents and ended up just deleting and re-creating the agent. You may try deleting your controller/agent and adding it back in. A brute-force solution but a good starting point. If that doesn't resolve the issue at least you can eliminate the controller/agent as the issue and take a look at network/server related issues.
Today is a happy day, since we managed to get to the bottom of the matter. Sorry #Duat that I'm taking away the 'answer' checkmark - but it turned out that the problem was quite different from what you (and anybody else) has predicted.
In my last update I was about to forward the matter to MS, when we realized that our Firewall was misbehaving in the name resolution. So we assumed this was the culprit & awaited for this to resolve. After this was resolved, we STILL had the same issues and we went again re-examining the situation.
We isolated the problem within our Build Process, more specific with a custom code activity included in our build solution.
I had implemented a code activity that would kick in at the final steps of every build. This activity was about gathering BuildDetails about the running build & add them as a new line in a 'BuildLog.xls'. Implementation made use of Microsoft.Office.Interop.Excel.This excel sheet resides in another server (NOT on the Servers where the controller/agents reside).
During development of this activity I was faced with issues like this, but after I was done no instances of EXCEL were left hanging. So I thought this was done & dealt with.
With try & error, we observed that when this activity wouldn't ran, no problems would occur.
With this activity running, the very first build after a build-controller reset would succeed, any next build had a certain chance to fail. Once any build failed, no other would succeed until another build-controller reset.
I have only a general understanding of what the problem was (Excel-call is DCOM, TFS services are WCF : How on earth would they interfere?! Why would this sometimes succeed and sometimes fail?! ).
The provided diagnostics were no help either, in fact they mislead us into a loop that continued for months.
If I ever find the time, I 'd like to cleanly reproduce the error & make a Server Fault question out of it...
After removal of this activity it works! I now searched in SO & found this, where J.Saunders comments: "In general, you should never use Office Interop from a server environment". It's ironic that once you get to the bottom of any difficult issue, the whole universe seems to have known about it except you...