This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi,
Are there any known issues with using LightSpeed in a threaded environment that I have not considered or maybe there are some cleanup calls that I’m not making when I should be?
|
|
|
LightSpeed should work fine in a threaded environment -- we, and many of our customers, use it to implement Web sites which are obviously highly multi-threaded environments! The only thing I can think of is if perhaps you are sharing the same unit of work across multiple threads and using that concurrently -- in that case multiple threads will be sharing the same MySqlConnection, and I'm pretty sure most DbConnection classes are not thread-safe. So I would try creating a unit of work per thread, or using PerThreadUnitOfWorkScope, and see if that resolves the problem. If that doesn't help, could you provide us with a small console application project (ideally including MySQL CREATE TABLE scripts for the database) that demonstrates the problem please? Thanks! |
|
|
Hi Ivan, I've created a test application for you to look at. It creates 25 threads and then does some random stuff on tables, nothing complicated. Although I cannot seem to reproduce the cast error in this code it does throw the SQL Connection errors after about 3 - 4 mins of running. The units of work are all created locally in the threads and I have even tried moving the context into each thread but still no help. I was wondering if it was because I was creating so many UOW's, one for each thread cycle instead of re-using ones I already have, perhaps the garbage collection is a little slow to react? I'm not sure what the PerThreadUnitOfWorkScope is for? Thanks Mike |
|
|
Hi Mike, Thanks for the detailed repro case. We have managed to reproduce the problem and are investigating. In the meantime, the problem appears to be happening in the LINQ layer, so as an interim measure you can work around it by using the core API query engine -- for example instead of: return uow.Table1s.Take(1).First() you can write return uow.Find<Table1>(new Query { Page = Page.Limit(1) }); We'll aim to get the LINQ issue fixed as soon as possible. Thanks again for letting us know about this. |
|
|
Hi Mike, I have committed a fix for this and it will be included in nightly builds dated 21 Feb 2009 and above, available from about 1430 GMT. Please let me know if you still see problems, and thanks once again for alerting us to the issue. |
|
|
Hi Ivan, that's great. I will download and try the update as soon as it is available. Cheers
|
|
|
Hi Ivan, I'm a little bit confused, I have downloaded the nightly build (version 2.2.973.10596?) and installed it but I am still having the exact same peoblem on the test app I sent you a few days ago? Is there something I am missing in the install? Thanks Mike |
|
|
Build 10596 should definitely include the multithreading LINQ fix. Can you check that your project is definitely referencing the updated version (e.g. remove and re-add the reference, clean and rebuild), and that the updated version has been copied into the project bin/Debug (or bin/Release) directory? Sometimes Visual Studio does not fully rebuild after a referenced DLL has been updated because it doesn't realise that the DLL has changed... You did mention in a previous message that you were seeing connection exceptions as well as cast exceptions. I only saw (and fixed) the cast exceptions -- I couldn't reproduce the connection exceptions. With the new version, are you still seeing cast exceptions, or only connection exceptions? |
|
|
Hi Ivan, I've been looking into this over the last 30 mins and it appears as though the cast issue has now been resolved in my original application, I have been running it for 10 mins with 20 threads without any problems however I am still seeing connection problems on the test app I sent you last week. Here is a screenshot of the problem when it kicks in.. http://81.21.74.111/tmp/sql_connection_error.png This error occures after about 2 to 3 mins of running. As I say, my main app has been running for over 10 mins without any issues, I dont know why the test app would be causing problems. |
|
|
Could you provide us with the stack trace for the MySql exception please? I wasn't able to reproduce this error using your test app myself unfortunately. Thanks! |
|
|
Sure, here it is... at MySql.Data.MySqlClient.MySqlDataReader.Read() |
|
|
Sure, here it is. the two ??'s on line 5 are not being displayed in my code, well they are showing as a funny unicode char instead of a function name. at MySql.Data.MySqlClient.MySqlDataReader.Read() |
|
|
I still haven't been able to reproduce the problem here but looking at the stack trace this *appears* to be an internal error in the MySQL driver. When opening a connection, the internal Driver.Configure method issues a SHOW VARIABLES call to the MySQL server, returning the result as a DataReader. It appears to be this reader which is being reported as being closed. From looking at the MySQL code, it looks as though this could happen if the SHOW VARIABLES call times out. However, the timeout for that call would be about 30 seconds, so I would expect you would see a noticeable slowdown long before you started getting exceptions (though I suppose this might also depend on how MySQL handles thread contention). Are you seeing anything like that? If this is the case -- and I can't see anything else that would explain the stack trace you've provided -- then I'm afraid there's not much we can do about it. You could try putting the statements in a TransactionScope, as this internally affects where we open the connection, but I don't think that would do much more than move the error somewhere else. You could also investigate whether there are any MySQL tuning parameters or connection string options that are recommended for multithreaded scenarios. Finally, you could of course try to throttle the number of threads -- you mentioned that you saw problems with 25 threads but not with 20 -- either manually or for example by using the thread pool depending on the nature of your app. |
|