Monthly Archives: June 2012

Pravopis – “vs.” versus “vs”

2 Replies

Občas potřebuji použít slovo versus ve zkrácené podobě a dlouho jsem nevěděl jestli je správně vs. nebo vs, případně obojí. Až do nedávna jsem s tím žil a trochu to ignoroval. Avšak dobrá nálada či co a větší než obvyklá četnost použití v jednom dni mne donutily se tomu podívat na zoubek.

Chvilka laborování s vyhledávačem a brouzdání po Ústav pro jazyk český a dostal jsem se na tuto stránku. Pokud přečtete celý text naleznete mj.:

Některé ustálené zkratky jsou tvořeny tak, že se píšou jen souhlásky (samohlásky se vypouštějí). Tak se např. zkracují některé vojenské hodnosti: kpt. = kapitán, mjr. = major, nstrm. = nadstrážmistr, plk. = plukovník, pplk. = podplukovník (ale gen. = generál). Podobně se píšou zkratky jako např. mld. = miliarda, rkp. = rukopis, rtg. = rentgen, vs. = versus.

Výsledek je jasný. Správně je vs. (tedy s tečkou).

Unobserved tasks in .NET 4.5

Leave a reply

When the Task and other related were introduced, there was behavior that informed you that you are possible doing something wrong. Yes, I’m talking about the exception being thrown from finalizer thread when your task completed as Faulted because of unhandled exception. I think this is absolutely correct behavior. If something as bas as unhandled exception happened I should take care of it no matter what. Because else I might corrupt some data or … what’s worse than corrupt data? ;)

In .NET 4.5 this behavior changed. The async/await brings some interesting considerations. Anyway. The above mentioned behavior was changed. Simply the exception is no longer thrown from finalizer. Good, bad? No matter what, I rather want my application to crash than to run happily next few hours and corrupt more data and do more mess.

Try to run this simple application (outside debugger, with optimization turned on):

Task t = Task.Factory.StartNew(() =>
	{
		Console.WriteLine("Task");
		throw new Exception();
		return 10;
	});
Thread.Sleep(1000);
GC.Collect();
GC.WaitForPendingFinalizers();
Thread.Sleep(1000);
Console.WriteLine("Done");

If you run it under .NET 4.0 you will get something like:

Unhandled Exception: System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.Exception: Exception of type 'System.Exception' was thrown.
   at ...
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.TaskExceptionHolder.Finalize()

Under .NET 4.5 it goes silently to Done. Bummer. If you have some opinion as I, you can luckily revert to the old behavior. Just add to you config into runtime section:

<ThrowUnobservedTaskExceptions enabled="true" />

Back on a safe side. Of course you can still use TaskScheduler.UnobservedTaskException event to be notified about unhandled exceptions from tasks, in case it happens (and it should not in 99,999% cases 8-)), no matter what settings you’re using. It’s just not that punch-me-into-face way with immediate process crash.

Awaiting something in TransactionScope

3 Replies

I like asynchronous programming. The Asynchronous Programming Model and later Tasks with ContinueWith offer great performance especially if no waiting and similar is used.

Although the async/await makes this very simple for 99% of cases, there’s always 1% where you might hit the wall. With callbacks it was little bit obvious, because you wrote the code. Now the compiler is doing the hard work.

If you do something like:

lock (SyncRoot)
{
	await FooBar.DoAsync();
}

You’ll get nice error from compiler saying The 'await' operator cannot be used in the body of a lock statement. And it really makes sense. The lock will very likely provide wrong results under default rewriting work the compiler is doing (and doing it properly for Monitor class needs a lot of knowledge of what you’re trying to achieve. What’s not so clear is that with TransactionScope block (or similar construct) you’re basically doing same stuff, just probably somewhere else in database.

So the compiler is completely OK with:

using (TransactionScope ts = new TransactionScope())
{
	await FooBar.DoAsync();
}

But that’s not what you might had in mind. Consider code like:

static void Main(string[] args)
{
	Test();
}

static async void Test()
{
	Task t = FooAsync();
	Console.WriteLine("Other stuff");
	await t;
}

static async Task FooAsync()
{
	using (Test t = new Test())
	{
		Console.WriteLine("Before");
		await Task.Yield();
		Console.WriteLine("After");
	}
}

class Test : IDisposable
{
	public void Dispose()
	{
		Console.WriteLine("Dispose");
	}
}

The result is correct (and expected, if you look at it closely):

Before
Other stuff
After
Dispose

But considering, that the Other stuff might have some dependency in data being done in that transaction you might get wrong result.

So it’s not always wrong, nor some gotcha in compiler. But think it through before using this construct.

Scaling with NuoDB

2 Replies

I know, there was a small gap between NuoDB related posts. I was little bit busy. But I’m now going to change it. In today’s post we’ll try to scale our chorus both in transactions and I/O throughput.

As you maybe remember from the first post, in NuoDB you have transaction and archive nodes. More transaction nodes means more queries/commands processed (yes, for badly designed application there might be other bottlenecks). And similarly with archive nodes that are in charge of persisting data to some storage and fetching data for mainly transaction nodes.

Simple. You already know how to start the agent and nodes from previous posts, but I think you will agree, that typing parameters on command line and keeping track what’s running where (and whether it’s running) is hard. This is where the NuoDB Console enters the game. It’s a simple application that shows you how your NuoDB world is looking.

Have a look at this picture (yeah, test machine is Windows XP 8-)).

You can see there’s one broker running on my ‘test’ machine. There are two choruses, with bunch of nodes. In this picture everything is on same machine, but in real environment you would probably have it across more machine. In ‘test‘ chorus is one archive node being started (the grayed one), currently not 100% ready and in ‘test2‘ chorus there is on the other hand some problem with one transaction node. For any problem you can check the log to see what’s wrong. From the same interface, using wizard, add nodes. Better than typing the commands again and again.

Computers running agents are being discovered automatically, but you can always add some manually if you know address, port and of course password.

This a great tool to start playing what happens when you kill (forcibly, that’s valid scenarios) some node and whether the chorus survives and all data are safe. My favorite scenario is one transaction node, two archive. Kill one archive node and continue inserting/querying data. Bring killed one back online and kill the other one. If you’re slow, the data will be synchronized, if not you’re screwed. :) BTW insert into table select * from table works so you can easily generated big results and long running commands.

And if I’m talking about playing, there’s also one program, that’s great for playing and seeing what’s going on. In samples\flights you can find application that allows you to put load to your setup. The bottom line is that you can play with number of clients (threads), also percent of updates and reconnect timeout. On the other hand in console you can try adding and removing nodes and see the system throughput. Whether it scales properly or whether you have some bottleneck there.


Wanna have more computing power? Add more machines with transaction nodes. Wanna be sure your data are safe in case of storage failure? Add more archive nodes. Also take into account, that each archive node holds complete data, not only some slices. So you should have enough free space available.

In next post we’ll deploy NuoDB into cloud (AWS) and use Amazon S3 as a storage for archive nodes (and as S3 in virtually unlimited, you don’t have to care about free space as mentioned above). Maybe I’ll also try flights demo in some medium size setup. ;)

Asynchronous semaphore

Leave a reply

I was just checking some documentation around System.Threading namespace for .NET 4.5 and I found that there’s one nice addition to synchronization primitives.

As you might imaging using async/await with synchronization primitives isn’t particularly good idea, because you can easily make a mistake and end up with code that looks correct but produces completely wrong results.

But still, for some primitives it might be useful. The BCL team (or whoever is responsible to this part) decided, the SemaphoreSlim is worth it. The method is SemaphoreSlim.WaitAsync.

Nice. This might nicely play with some legacy threading code.

WUG: Zkušenosti s tvorbou a provozem aplikací na Windows Azure

2 Replies

Cloud (Azure) je super. Ale tupý vstup do toho světa je téměř jistě recept na neúspěch. Pokud vás zajímají některé koncepty, které je třeba podchytit a případně slepé cesty, přijďte.

Anotace:

Tato all hands přednáška se zaměří na praktické aspekty provozu aplikace na Windows Azure. Klasická “dos and don’ts”, “gotchas” apod. Provozovat aplikaci v cloudu není těžké, ale provozovat ji efektivně a dlouhodobě znamená někdy vyzkoušet i slepé cesty, poznat svoje omyly a zaplatit daň v podobě nutného předělání. Znalosti, které nasdílíme doufejme tyto slepé cesty omezí. Samozřejmě se podíváme i některé fígle a triky, které mohou používání usnadnit a využít naplno potenciál platformy.

Registrace aspol. na wug.cz.