I am using the following transaction
var transactionScopeOptions = new TransactionOptions() { IsolationLevel = IsolationLevel.ReadUncommitted, Timeout = Timeout = new TimeSpan(0, 10, 0) };
using (TransactionScope transactionScope = new TransactionScope(TransactionScopeOption.Required, transactionScopeOptions))
{
/* update query here with data context execute command */
}
And I keep getting The operation is not valid for the state of the transaction exception with the inner exception of Transaction Timeout.
Locally I only get in 1 in 100,000 chances, but in the server it happens like every now and then. The application is running on MSMQ and WCF.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,
ConcurrencyMode = ConcurrencyMode.Multiple)]
I have tried the following:
<system.transactions>
<machineSettings maxTimeout="02:00:00" />
</system.transactions>
and setting the dataContext.CommandTimeout to 1 hour or 0 (infinite).
Changed the Connection Timeout=3600 in the app.config
I have tried almost everything I've read on Google but still no luck. Hope I can remove this problem in the server.
NOTE: update query usually last between 0 to 20 seconds (max) but since it's multithreading, it causes the error. If I ran the ones in the exception, it doesn't seem to get the error anymore either because the transaction doesn't time out.
EDIT:
All my queries have dirty read (nolock for reads and rowlock for updates)
EDIT:
Component Services > My Computer > Options > Transaction Timeout (seconds): 600
Then restarted "Distributed Transaction Coordinator" in services.
Still no luck
EDIT:
Timestamp was added when entering the transactionScope and when getting the exception (Transaction TimeOut) it seems it is not really time out related because it is kicked out less than a minute from entering the transaction scope (when I already specified the transaction to have a time out in 10 minutes).
This means it just gives out Transaction TimeOut exception even if it really didn't timed out.
EDIT:
Based on the last error, I tried adding the following, based from this website to my connection string:
Transaction Binding=Explicit Unbind
Though I am using SQL Server 2012 and latest Visual Studio Framework, so not sure it helps at all.
EDIT:
I also have the following:
In the app config:
<system.transactions>
<defaultSettings timeout="2:00:00" />
</system.transactions>
binding services:
<binding name="FooBinding"
deadLetterQueue="System"
maxReceivedMessageSize="524288"
exactlyOnce="true"
receiveErrorHandling="Move"
retryCycleDelay="00:00:30"
maxRetryCycles="120"
receiveRetryCount="0"
sendTimeout="00:01:00">
and
<serviceTimeouts transactionTimeout="00:10:00" />
EDIT:
I tried changing the config to the following, hoping it was a WCF timeout (default is 1 minute) but still get those exceptions: (extend timeout to 10 minutes)
<binding name="FooBinding"
deadLetterQueue="System"
maxReceivedMessageSize="524288"
exactlyOnce="true"
receiveErrorHandling="Move"
retryCycleDelay="00:00:30"
maxRetryCycles="120"
receiveRetryCount="0"
closeTimeout="00:10:00"
openTimeout="00:10:00"
receiveTimeout="00:10:00"
sendTimeout="00:10:00" />
I asked a related question with some code logic in another link.
Related
Imagine you are using or developing an automated test for the T32-Remote API. In this case the C-API is wrapped into Java.
The connection is initialized with:
T32_Config("NODE=", "localhost"));
T32_Config("PACKLEN=", "1024"));
T32_Config("PORT=", "20000"));
T32_Init());
T32_Attach(T32.T32_DEV_ICE);
After that, the test starts and is aborted unexpectedly by the user without calling:
T32_Exit();
If you are restarting the test again now, this results in a connection error at T32_Attach() returning -1 (T32_ERR_COM_RECEIVE_FAIL). Restarting a second time does not cause any issues.
Is there any way from within the remote API to reset Trace32? Closing the program and open it again or restarting the test a second time is not an option.
I do not really know why this fixed the issue but if an error occurs, simply run the entire initialization routine again.
1st time: T32_Exit() not called
2nd time: simply do this
T32_Config("NODE=", "localhost"));
T32_Config("PACKLEN=", "1024"));
T32_Config("PORT=", "20000"));
T32_Init());
if(T32_Attach(T32.T32_DEV_ICE) != 0){
T32_Config("NODE=", "localhost"));
T32_Config("PACKLEN=", "1024"));
T32_Config("PORT=", "20000"));
T32_Init());
T32_Attach(T32.T32_DEV_ICE)
}
Building an app with presence following the firebase docs, is there a scenario where the on-disconnect fires when the app is still connected? We see instances where the presence node shows the app as going offline and then back online within a few seconds when we aren't losing a network connection.
We are seeing on multiple embedded devices installed in the field where presence is set to false and then almost immediately right back to true and it's occurring on all the devices within a few seconds of each other. From the testing we have done and the docs online we know that if we lose internet connection on the device it takes roughly 60 seconds before the timeout on the server fires the onDisconnect() method.
We have since added code in the presence method that allows the device if it sees the presence node be set to false while the app is actually running it will reset the presence back to true. At times when this happens we get a single write back to true and that is the end of it, other times it is like the server and client are fighting each other and the node is reset to true numerous times over the course of 50-200 milliseconds. We monitor this by pushing to another node within the device GUID each time we are forcing presence back to true. This only occurs while the module is running and after it initially establishes presence.
Here is the method that we call from our various modules that are running on the device so that we can monitor the status of each of the modules at any given time.
exports.online = function (program, currentProgram) {
var programPath = process.env.FIREBASE_DEVICES + process.env.GUID + '/status/' + program
var onlinePath = process.env.FIREBASE_DEVICES + process.env.GUID + '/statusOnlineTimes/' + program
var programRef = new firebase(programPath);
var statusRef = new firebase(process.env.FIREBASE_DEVICES + process.env.GUID + '/status/bootup');
var onlineRef = new firebase(onlinePath)
amOnline.on('value', function(snapshot) {
if (snapshot.val()) {
programRef.onDisconnect().set(false);
programRef.set(true);
programRef.on('value', function(snapshot){
if (snapshot.val() == false){
programRef.set(true);
console.log('[NOTICE] Resetting', program, 'module status back to True after Fireabase set to False')
var objectToPush = {
program: program,
time: new Date().toJSON()
}
onlineRef.push(objectToPush)
}
})
if (currentProgram != undefined) {
statusRef.onDisconnect().set('Offline')
statusRef.set(currentProgram)
}
}
});
The question we have is there ever an instance where Firebase is calling the onDisconnect() method even though it really isn't losing its status? We had instances where we would see the device go offline and then back online within 60 seconds before we added the reset code. The reset code was to combat another issue we had in the field where if the power were interrupted to the device and it did not make a clean exit, the device could reboot and and reset the presence with a new UID before the timeout for the prior instance had fired. Then once the timeout fired the device would show as offline even though it was actually online.
So we were able to stop the multiple pushes that were happening when the device reconnected by adding a programRef.off() call directly before the programRef.on(...) call. What we determined to be happening is that anytime the device went online from an offline state and the amOnline.on(...) callback fired it created a new listener.
Now we are able to handle the case where a onDisconnect() fires from a earlier program PID and overwrites the currently active program with a status of offline. This seems to solve the issue we are having with the race condition of the devices in the field able to reboot and regain connection prior to the onDisconnect() firing for the instance that was not cleanly exited.
We are still having an issue where all of the devices are going off and then back online at approximately the same time (within 1-3 seconds of each other). Are there any times where Firebase resets the ./info/connected node? Because we are monitoring presence and actually logging on and off events maybe we are just catching an event that most people don't see? Or is there something that we are doing wrong?
Something strange is happening with my app, I am using SailsJs with official PostgreSQL driver and my data gets deleted. I don't have any pattern or list of specific events which deletes the data but I have following observations.
Few days back i was writing a function to destroy data and when I
executed that function it gave me an error I fixed the error and ran
my web app again and whoa data from one of my table was all gone.
Yesterday i wrote a function and I tried to get the HTTP call to that
function but it was giving me 500 server error, I started debugging it
and after executing my program 3 to 4 times with this error partial
data was deleted from one of my database table. Later the error was i
had a typo in URL.
If any of you guys had any experience with what is happening to me please let me know how to fix it? or at least help me on how to reproduce this issue ?
EDIT
I activated the logs and was waiting for it to happen again and it happened again and here is the log from sailsjs
In the logs I saw that its talking about alter.js sync strategy but i have selected it to be the safe strategy
It has happened to me quite a few times, when lifting the app and it is in the process of making changes to the db and it fails, sometimes due to ORM timeout.
What sails do when its lifting and needs to update the data structure is controlled in config/models.js migrate: 'alter', usually commented out, you get a prompt for what to do 1... 2... 3... (writing from the top of my head, i dont remember the actual messages) and a warning about using alter on a production system.
Changing
config/orm.js to have this
// config/orm.js
module.exports.orm = {
_hookTimeout: 60000 // I used 60 seconds as my new timeout
};
And for reasons I don't know changing config/pubsub.js
// config/pubsub.js
module.exports.pubsub = {
_hookTimeout: 60000 // I used 60 seconds as my new timeout
};
has helped me, avoid data loss.
I am running ServiceStack 3.97 and just added the RequestLogger plugin - amazing that it is built-in, just what I needed. The worrisome thing I noticed once I tried it is that it says all the previous GET requests have "is running = true".
For example, I issued a few requests in a browser tab (pressing F5 a few times, and closed tab) and can see them show up here /api/requestlogs. In the items column, the elapsed time keeps ticking each time I refresh and is running is always true.
This is very scary as it appears to be saying that the requests remain open. If so, it could be related to an unknown error I get over time whereby SS is unable to return an Open connection.
Here is a sample of the items field:
_request Duration Stopwatch
is Running true
elapsed PT8M31.5460178S
elapsed Milliseconds 511546
elapsed Ticks 1395611107
Any suggestions or ideas as to why this is happening and/or how to dig deeper? What would keep GETs open?
The RequestLogger takes a 'snapshot' which includes a dump of the Request.Items dictionary (which contains a Stopwatch) into a rolling log of DTO's, but this doesn't keep the request 'open' as you might think, so there's no need for concern.
I am trying to use the couchdb (continuous) changes API from Java and find that after exhausting the list of current changes the stream seems to be closed, not stay open forever as it is supposed to.
The code I am using is below. I would expect to never drop out of the while loop, but do as soon as the currently existing changes are finished being streamed. I am relatively new to both couchdb and Java so may be missing something obvious. Can anyone show me how to write this correctly?
URL url = new URL("[path to database here]/_changes?feed=continuous";);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setDoOutput(true);
conn.setUseCaches(false);
conn.setRequestProperty("Connection", "Keep-Alive");
conn.setRequestMethod("GET");
BufferedReader reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
String line;
while((line = reader.readLine()) != null){
// do something with the line here
}
// Should never get here under normal circumstances
reader.close();
There's actually a default timeout of 60000ms (60 seconds) unless a different timeout value or a heartbeat is provided. I updated the _changes wiki page back in October and included any defaults I came across in the code.
Setting the heartbeat basically means that you'll be watching for a timeout in the client, i.e. no newline for the heartbeat period means you've definitely lost your connection. I believe CouchDB disables its timeout check if there's a heartbeat.
In any case, you should probably expect the connection to be closed at some point and code for that condition.
You can use &heartbeat=1000 to get couchdb sending new lines over the wire every second. That will keep your connection open until you disconnect and/or CouchDB gets shut down.
But you are right, I would also have expected that the connection won't close - seems as if also conn.setReadTimeout(0); doesn't help anything.
This is just a guess since I dont know enough about the couchdb continuousfeed implementation or the HttpUrlConnection implementation. But it seems barring any bugs in the code of the two that if your java connection client has a timeout set lower than the default heartbeat for couchdb continuous changes then the connection could get terminated by the java client.
Just a thought.