This article is also available in english.

Depuis quelques temps, avec la sortie du Rx Framework et de la programmation réactive/interactive, quelques fonctionnalités intéressantes sont ressorties au travers d’un très bon article de Bart De Smet's à propos de System.Interactive et du “lazy-caching”.

Lorsque l’on utilise LINQ, on trouve deux sortes d’opérateurs : Les opérateurs “Lazy” qui prennent les éléments au fur et à mesure et qui les envoient à mesure qu’ils sont sollicitiés (Select, Where, SelectMany, First, …) et les opérateurs que j’appelerais “rendez-vous” pour lesquels la totalité des éléments de l’énumérable doit être énumérée (Count, ToArray/ToList, OrderBy, …) pour qu’ils produisent un résultat.

Opérateurs “Lazy”

Les opérateurs Lazy sont très intéressants car ils permettent justement d’obtenir de bonnes performances lorsque l’on estime ne pas avoir besoin d’énumérer la totalité de l’énumérable. Cela peut-être aussi utile lorsqu’il est très long d’énumérer tous les éléments de l’énumérable, et que l’on veut n’en récupérer que quelques uns des premiers.

Par exemple :

static IEnumerable<int> GetItems()
{
    for (int i = 0; i < 5; i++)
    {
        Console.WriteLine(i);
        yield return i + 1;
    }
}

static void Main()
{
   Console.WriteLine(GetItems().First());
   Console.WriteLine(GetItems().First());
}

Va simplement écrire :

0
1
0
1

On ne va donc énumérer que le premier élément de l’énumérateur GetItems().

Ces opérateurs ont cependant un comportement très important à connaitre: chaque fois qu’ils sont énumérés, ils énumèrent à nouveau leur source. Cela peut-être aussi bien un avantage (énumérer plusieurs fois une source qui change) qu’un inconvénient (énumérer plusieurs fois une source couteuse en ressources).

Opérateurs “Rendez-vous”

Ces opérateurs quant à eux sont très intéressants parcequ’ils permettent justement d’énumérer la totalité de l’énumérateur, et dans le cas particulier de ToArray, permet d’avoir une version immuable du contenu l’énumérateur. Ils permettent justement d’éviter que les opérateurs lazy n’énumèrent à nouveau leur source si l’on veut itérer plusieurs fois sur leurs éléments.

Si l’on reprend l’exemple précédent, avec ce code :

static void Main()
{
   var items = GetItems().ToArray();
   Console.WriteLine(items.Count());
   Console.WriteLine(items.Count());
}

On va avoir ce résultat :

0
1
2
3
4
5
5

Puisque Count a besoin de connaître la totalité des éléments de l’énumérable source pour en déterminer le compte.

Ces opérateurs, eux aussi, énumèrent leur source à chaque utilisation.

Le cas de l’énumération multiple

Un exemple concret de problème posé par l’énumération multiple est la création d’un opérateur de partitionnement d’énumérable. Dans l’exemple donné dans cet article, on peut voir que l’énumérable passé en source est utilisé dans deux clauses “where” différentes, ce qui implique une double énumération de l’énumérable source. Stocker la totalité de l’énumérable source par l’intermédiaire d’un ToArray/ToList serait faisable, mais serait une perte de ressources potentielle puisque l’on ne sait pas si l’énumérable de sortie sera énuméré en totalité (si tenté que ce soit possible, puisque dans le cas d’un énumérable infini, ToArray n’est pas applicable).

Il faudrait donc un intermédiaire entre les opérateurs “Lazy” et “Rendez-vous”.

EnumerableEx.MemoizeAll

La classe EnumerableEx apporte une extension, MemoizeAll (tirée du concept de Memoization), qui permet d’avoir cette sorte de juste milieu, et va finalement cacher les éléments de l’énumérable source au fur et à mesure qu’ils sont récupérés. Une sorte de ToArray “lazy”.

Si l’on reprend l’exemple de l’article de Mark Needham, on ferait donc ceci :

var evensAndOdds = Enumerable.Range(1, 10).MemoizeAll().Partition(x => x % 2 == 0);

Dans le cas de cet exemple, le MemoizeAll n’a que très peu d’intéret coté performance, puisque l’énumération de Enumerable.Range ne coute que très peu cher. Mais dans un cas où la source de “Partition” serait un énumérable beaucoup plus couteux, comme une query Linq2Sql par exemple, le caching “lazy” peut se révéler intéressant.

Un des commentaire suggère de faire un implémentation à base de GroupBy, mais cet opérateur évalue à nouveau l’énumérable source lorsqu’un groupe est énuméré. MemoizeAll est aussi tout à fait pertinent, même dans le cas d’un GroupBy. Cela dit, cela reste toujours un compromis entre utilisation mémoire et ressources processeur.

En passant, Bart de Smeth discute de la partie élimination des effets de bords lié à l'énumération multiple d'énumerables par l'utilisation de Memoize et MemoizeAll, ce qui n'est pas vraiment un problème dans ce cas, mais qui est un sujet tout aussi intéressant.

.NET 4.5 ?

Dans une note à part, je trouve dommage que les extensions de EnumerableEx ne se soient pas retrouvées dans .NET 4.0... Elles sont fort utiles, et sont finalement assez peu complexes. Elles sont peut-être arrivées trop tard durant le cycle de développement de .NET 4.0. Dans .NET 4.5, peut-être :)

This post is available in english.

Télécharger ici le code source de cet article.

Lorsque l’on essaye d’appliquer le modèle MVC aux WinForms, on peut se faciliter la vie en utilisant l’interface INotifyPropertyChanged pour faire du DataBinding entre le contrôleur et le formulaire.

On peut donc écrire un contrôleur qui ressemble à ceci :

    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
    public class MyController : INotifyPropertyChanged
    {
        // Register a default handler to avoid having to test for null
        public event PropertyChangedEventHandler PropertyChanged = delegate { };

        public void ChangeStatus()
        {
            Status = DateTime.Now.ToString();
        }

        private string _status;

        public string Status 
        {
            get { return _status; }
            set 
            { 
                _status = value;

                // Notify that the property has changed
                PropertyChanged(this, new PropertyChangedEventArgs("Status"));
            }
        }
    }

Le formulaire est defini comme ceci :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
    public partial class MyForm : Form
    {
        private MyController _controller = new MyController();

        public MyForm()
        {
            InitializeComponent();

            // Make a link between labelStatus.Text and _controller.Status
            labelStatus.DataBindings.Add("Text", _controller, "Status");
        }

        private void buttonChangeStatus_Click(object sender, EventArgs e)
        {
            _controller.ChangeStatus();
        }
    }

Le formulaire va donc mettre à jour le label “labelStatus” lorsque la propriété “Status” du contrôleur change.

Tout ce code est executé dans la thread principale, celle où la pompe à messages du formulaire principal est placée.

Une touche d’asynchronisme

Imaginons maintenant que le contrôleur va effectuer un certain nombre d’opérations en asynchrone, par l’intermédiaire d’un timer par exemple.

Modifions le contrôleur en ajoutant ceci :

1
2
3
4
5
6
7
8
9
10
11
 
        private System.Threading.Timer _timer;

        public MyController()
        {
            _timer = new Timer(
                d => ChangeStatus(), 
                null,
                TimeSpan.FromSeconds(1),   // Start in one second
                TimeSpan.FromSeconds(1)    // Every second
            );
        }

En modifiant le contrôleur de cette manière, on va faire en sorte que la propriété Status soit mise à jour régulièrement.

Le modèle de fonctionnement de System.Threading.Timer fait en sorte que la méthode ChangeStatus est appelée depuis une thread différente de celle qui a créé le formulaire. Ainsi, lorsque le code s’exécute, la mise à jour du label se fait arrêter avec l’exception suivante :

   Cross-thread operation not valid: Control 'labelStatus' accessed from a thread other than the thread it was created on.

La solution est assez simple, il faut faire en sorte que la mise à jour se fasse sur la Thread principale en utilisant la méthode Control.Invoke().

Cela dit dans notre contexte, c'est l'engin de DataBinding qui s'attache à l'événement PropertyChanged. Il faut donc faire en sorte d’appeler l’événement PropertyChanged en le “décorant” d’un appel à la méthode Control.Invoke().

On pourrait modifier le contrôleur pour appeler l’évènement sur la Thread principale :

1
2
3
4
5
6
7
8
 
    set 
    { 
        _status = value;

        // Notify that the property has changed
        Action action = () => PropertyChanged(this, new PropertyChangedEventArgs("Status"));
        _form.Invoke(action);
    }

Mais cela impliquerait d’ajouter du code dépendant des WinForms dans le contrôleur, ce qui n’est pas acceptable. Comme on veut être capable de placer ce contrôleur dans un test unitaire, appeler la méthode Control.Invoke() poserait problème, puisqu’il faudrait une instance de formulaire, que l’on aurait pas dans ce contexte.

La délégation par interface

L’idée est donc déléguer à la vue (donc au formulaire) la responsabilité de placer l’appel de l’évènement sur la thread principale. On peut le faire par l’intermédiaire d’une interface passée en paramètre du constructeur du contrôleur. Une interface comme ceci :

1
2
3
4
 
    public interface ISynchronousCall
    {
        void Invoke(Action a);
    }

On fait en sorte que le formulaire l'implémente :

1
2
3
4
5
 
    void ISynchronousCall.Invoke(Action action)
    {
        // Call the provided action on the UI Thread using Control.Invoke()
        Invoke(action);
    }

Puis on va lever l’évènement comme ceci :

1
2
3
 
    _synchronousInvoker.Invoke(
        () => PropertyChanged(this, new PropertyChangedEventArgs("Status"))
    );

Mais comme tout bon programmeur efficace (entendez paresseux), on veut éviter d'écrire une interface.

La délégation par lambda

On va donc tenter d’utiliser les lambda pour appeler la méthode Control.Invoke(). Pour faire cela, on va modifier le constructeur du contrôleur, et plutôt que de prendre une interface en paramètre, on va écrire :

1
2
3
4
5
 

    public MyController(Action<Action> synchronousInvoker)
    {
        _synchronousInvoker = synchronousInvoker;
        ...
    }

En clair, on donne au constructeur une action qui a pour responsabilité d’appeler une action qui lui est passée en paramètre.

Cela permet de construire le contrôleur de cette manière :

1
 

    _controller = new MyController(a => Invoke(a));

Ici, pas d'interface à implémenter, juste une petite lambda qui fait l'invocation d'une Action sur la Thread GUI. Et on l’utilise comme ceci :

1
2
3
 

    _synchronousInvoker(
        () => PropertyChanged(this, new PropertyChangedEventArgs("Status"))
    );

Cela veut donc dire que la lambda spécifiée en paramètre sera appelée par la Thread UI, donc dans le bon contexte pour mettre à jour le label associé.

Le contrôleur est effectivement toujours isolé de la vue, mais adopte malgré tout le comportement de la vue pour les changement de propriétés.

Si l’on voulait utiliser le contrôleur dans un cadre de test unitaire, on le construirait de cette manière :

1
 

    _controller = new MyController(a => a());

La lambda spécifiée ne se contenterait alors que d'appeler directement l'action en paramètre.

Bonus: Faciliter l’écriture du code de notification

Un désavantage de passer INotifyPropertyChanged est qu’il est nécessaire d’écrire le nom de la propriété sous forme de chaine de caractères. C’est assez gênant pour plusieurs raisons, notamment lors de l’utilisation d’outils de refactoring ou d’obfuscation.

C# 3.0 apporte les arbres d’expressions, une fonctionnalité intéressante qui peut être utilisée dans ce contexte. L’idée est d’utiliser les arbres d’expressions pour faire une sorte d’hypothétique “memberof” qui permettrait d’obtenir le MemberInfo d’une propriété, de la même manière que typeof permet d’obtenir le System.Type d’un type.

Voici une petite méthode d’aide à la levée d’évènements :

1
2
3
4
5
6
7
8
9
 
    private void InvokePropertyChanged<T>(Expression<Func<T>> expr)
    {
        var body = expr.Body as MemberExpression;

        if (body != null)
        {
                PropertyChanged(this, new PropertyChangedEventArgs(body.Member.Name));
        }
    }

Méthode que l'on va utiliser comme ceci :

1
2
3
 
    _synchronousInvoker(
        () => InvokePropertyChanged(() => Status)
    );

Ainsi la propriété “Status” est utilisée en tant que propriété dans le code, et non en tant que chaine de caractère. Il devient alors facile de la renommer via un outil de refactoring sans casser la logique du code.

Il faut noter que la lambda () => Status n’est jamais exécutée. Elle est simplement analysée par la méthode InvokePropertyChanged comme étant capable de fournir le nom d’une propriété.

Le contrôleur en un seul morceau

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
    public class MyController : INotifyPropertyChanged
    {
        // Register a default handler to avoid having to test for null
        public event PropertyChangedEventHandler PropertyChanged = delegate { };

        private System.Threading.Timer _timer;
        private readonly Action<Action> _synchronousInvoker;

        public MyController(Action<Action> synchronousInvoker)
        {
            _synchronousInvoker = synchronousInvoker

            _timer = new Timer(
                d => Status = DateTime.Now.ToString(),
                null,
                1000,   // Start in one second
                1000    // Every second
            );
        }

        public void ChangeStatus()
        {
            Status = DateTime.Now.ToString();
        }

        private string _status;

        public string Status
        {
            get { return _status; }
            set
            {
                _status = value;

                // Notify that the property has changed
                _synchronousInvoker(
                    () => InvokePropertyChanged(() => Status)
                );
            }
        }

        /// <summary>
        /// Raise the PropertyChanged event for the property “get” specified in the expression
        /// </summary>
        /// <typeparam name="T">The type of the property</typeparam>
        /// <param name="expr">The expression to get the property from</param>
        private void InvokePropertyChanged<T>(Expression<Func<T>> expr)
        {
            var body = expr.Body as MemberExpression;

            if (body != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(body.Member.Name));
            }
        }
    }

Dans les fonctionnalités intéressantes de SharePoint 2007 (ou WSS 3.0), on peut trouver la possibilité de naviguer dans le contenu d’un site en l’utilisant comme un lecteur réseau. Cela est possible grâce au protocole WebDAV que Microsoft a utilisé pour implémenter cette fonctionnalité.

Si vous installez WSS 3.0 sur un Windows Server 2008 R2, vous allez rapidement vous rendre compte que cette fonctionnalité ne marche pas vraiment, puisqu’elle donnant des erreurs du type “Access Denied” ou “The network path could not be found” lorsque l’on essaye de connecter un lecteur réseau.

Avec IIS 6.0, pour régler un problème similaire, il suffisait simplement de s’assurer que l’extension WebDAV était “interdite”.

Avec IIS 7.5, WebDAV est mentionné à plusieurs endroits, mais il n’y en a qu’un seul à modifier :

• Ouvrez la section de configuration “Modules” pour le site web Sharepoint
• Trouvez l’entrée “WebDAVModule”
• Supprimez la, et voilà !

La partie intéressante dans tout cela est que, bien que le composant WebDAV est désactivé dans toutes les sections possibles du site, le module WebDAV d’IIS intercepte malgré tout le verbe WebDAV PROPFIND et retourne une erreur 405 (Not Allowed).

Puisque ce verbe est géré par un httpHandler ASP.NET de SharePoint, ce handler n’a pas la chance de traiter ce verbe... Et vous ne voyez pas vos fichiers dans l’Explorateur Windows.

Si vous commencez à vous tester Visual Studio 2010, en tentant d’ouvrir un fichier source dans le “Solution Explorer” vous tomberez peut-être sur une belle exception comme celle ci :

---------------------------
Microsoft Visual Studio
---------------------------
Object reference not set to an instance of an object.
---------------------------
OK
---------------------------

On ne peut pas vraiment plus opaque…

Après une petite analyse avec un debugger, il semblerait que VS2010 ne supporte que les fontes TrueType, mais n’empèche pas leur sélection dans la boite de sélection des fontes.

Pour ma part, j’utilisait “Proggy Opti Small” avec VS2008, qui n’est pas TrueType... Pour pouvoir ouvrir vos fichier source, selectionnez une fonte normale, comme par exemple Consolas et redémarrez VS2010.

Un rapport existe sur Connect.

This post is also available in english.

En utilisant Hyper-V Server, vous allez peut-être constater que l’horloge dérive beaucoup du temps “réel”, en particulier lorsque les machines virtuelles “invitées” utilisent fortement les CPUs. Comme l’OS de l’hôte est également virtualisé, cela implique que sa charge fait aussi dériver l’horloge système.

Comment atténuer la dérive de l’horloge

1. Désactiver la synchronisation du temps dans la section “Integration Services”. (Attention, ce paramètre est défini par snapshot)
2. Importer le fichier de registre suivant :
   
   Windows Registry Editor Version 5.00

   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config]
   "MaxAllowedPhaseOffset"=dword:00000001
   "SpecialPollInterval"=dword:00000005
   "SpecialInterval"=dword:00000001
   
   Note: Si vous utilisez notepad, assurez vous de sauver le fichier en utilisant un encodage Unicode.

3. Si l’OS “invité” ne fait pas partie d’un domaine, exécutez la ligne suivante pour définir une source de temps :
   
   w32tm /config /manualpeerlist:"time.windows.com 1.ca.pool.ntp.org 2.ca.pool.ntp.org" /syncfromflags:MANUAL /update
   
   Note: Les FQDN des hôtes sont séparés par des espaces.
   
4. Executer la commande suivante pour forcer une synchronisation du temps :
   w32tm /resync
   
5. Vérifier que l’horloge ne dérive plus avec la commande suivante :
   
   w32tm /monitor /computer:time.windows.com

Un peu d’histoire...

Le système sur lequel je travaille en ce moment se sert énormément du temps, et l’utilise pour prendre les instants de différentes étapes du process. Si pour une raison quelconque l’horloge système devient instable, cela implique que les données générées ne sont plus fiables. Cela peut générer de temps à autres des données corrompues, et ce n’est pas bon pour le business...

J’étais en train d’investiguer une séquence d’événements stockés dans une base de données dans un ordre qui ne pouvait pas s’être produit, parce que le code ne peut pas les générer de cette manière.

Après beaucoup de recherche pour trouver des erreurs dans le code, je suis tombé sur quelque chose d’assez étrange dans les logs de mes applications. Considérant que chacune des lignes est générée par la même thread, et que le temps d’une ligne doit être ultérieur à la ligne précédente :

2009-10-13T17:15:26.541T [INFO][][7] ...
2009-10-13T17:15:26.556T [INFO][][7] ...
2009-10-13T17:15:24.203T [INFO][][7] ...
2009-10-13T17:15:24.219T [INFO][][7] ...
2009-10-13T17:15:24.234T [INFO][][7] ...

Comme ces lignes ont été générées par la même thread, cela veut dire que l’heure système a été radicalement changée entre la deuxième et la troisième ligne. Du point de vue le l’application, le temps est revenu en arrière d’environ deux secondes et que durant ces deux secondes la base de donnée contenait des données générées dans le futur. Ce n’est pas très bon...

L’investigation

En regardant le code source de Log4net, j’ai pu confirmer que le temps est récupéré en utilisant un appel à System.DateTime.Now, ce qui de fait exclut une erreur de code.

J’ai ensuite regardé l’état du service de temps de windows, et en exécutant la commande suivante :

w32tm /stripchart /computer:time.windows.com

J’ai remarqué que la différence de temps entre mon système et le NTP distant était très grande, quelque chose comme 10 secondes. Mais le plus dérangeant n’est pas la différence de temps, mais l’évolution de cette différence de temps.

Dépendant de la charge CPU de la machine virtuelle, la différence de temps devenait très grande au point d’attendre une seconde de retard en moins d’une minute. La machine “invitée” et l’hôte présentaient ce comportement. Comme Hyper-V Integration Services synchronise par défaut l’horloge de toutes les machines virtuelles avec celle de la machine hôte, cela implique de la charge d’une seule des machine influence l’horloge de toutes les autres. La machine hôte peut elle même influencer la cadence globale de l’horloge, puisqu’elle est elle-même virtualisée.

Essai d’explication du phénomène

En essayant de faire une explication éclairée, la source du temps utilisée par windows est le TSC du processeur (par l’utilisation de l’opcode RDTSC), qui est virtualisé. La préemption du CPU par les autres machines virtuelles semble avoir un impact négatif sur le compteur utilisé comme référence par windows.

Plus le CPU est préempté, plus le compteur dérive.

Corriger la dérive

Par défaut, le Service de Temps a un procédé “d’ajustement de phase” qui ralentis ou accélère la cadence l’horloge système pour qu’elle se rapproche de celle d’une source de temps fiable. Le compteur TSC sur le processeur physique est cadencé par le Quartz système (Si cela est toujours le cas). La dérive “normale” de ce genre de composant n’est généralement pas très important, et peut être lié à des facteurs externes tels que la température ambiante. Le service de temps peut gérer sans problème ce genre de dérive lente.

Mais la configuration par défaut semble ne pas être appropriée pour une source de temps qui dérive très rapidement et de manière imprévisible. Il faut donc augmenter la fréquence de l’opération d’ajustement de phase.

Modifier cela est relativement simple, le service de temps doit corriger plus fréquemment la cadence de l’horloge, afin de compenser la charge des machines virtuelles qui ralentissent la cadence de l’horloge.

Les paramètres par défaut dans Hyper-V Server R2 sont ceux d’une machine membre d’un domaine, et qui sont définies ici. La période de récupération du temps depuis une source fiable est beaucoup trop longue, 3600 secondes, considérant la vitesse de dérive de l’horloge.

Quelques paramètres doivent donc être ajustés dans la base de registre pour permettre à l’horloge de rester synchronisée :

• Assigner la valeur 0x1 à SpecialInterval pour permettre l’utilisation de SpecialPollInterval.
• Assigner 10 à SpecialPollInterval pour forcer la lecture de la source NTP toutes les 10 secondes.
• Assigner 1 à MaxAllowedPhaseOffset to 1, pour définir la dérive maximale à une seconde, après quoi l’horloge sera assignée directement si la modification de la cadence de l’horloge ne fonctionne pas.

L’utilisation de ces paramètres ne permet pas d’avoir une horloge parfaitement stable, mais elle va au moins être corrigée rapidement.

Il semblerait qu’un paramètre caché du boot.ini pour Windows 2003, /USEPMTIMER, qui force windows à utiliser le timer ACPI et éviter ce genre de dérive. Je n’ai pas pu confirmer que ce paramètre a quelque sorte d’effet. Je n’ai pas non plus trouvé de méthode pour confirmer quel timer est utilisé par windows.

Immaginez avoir une application WinForms relativement complexe, et que les sirènes de WPF sont tellement attirantes, que vous voulez intégrer un contrôle WPF dans un formulaire quelque part perdu dans l'application. Le formulaire question est ouvert et fermé souvent.

La solution est de coder son contrôle WPF, puis de l'intégrer dans une application WinForms en utilisant ElementHost, ce petit bout de "magie" qui fait gagner bien du temps.

Rapidement, on constate que le chargement du contrôle WPF prend énormément de temps... Sur ma machine, un Core2 Duo 3Ghz, cela prend à chaque ouverture du formulaire quelque chose comme 3 à 4 secondes avant d'afficher proprement le formulaire qui contient le ElementHost. Et non content de ralentir le chargement du formulaire, l'affichage se faire par morceaux... Pas très fancy... Simple intuition, mais cela ressemble au chargement du runtime de WPF qui prend du temps...

La solution pour améliorer tout ca est relativement simple : Il suffit de garder un contrôle ElementHost "vide" visible en tout temps. Placer un contrôle de type ElementHost de taille 1x1 quelque part dans une fenêtre qui reste visible tout au long de l'exécution de l'application.

Le résultat, le formulaire s'affiche sans aucun délai ni problème visuel. Bien entendu, le chargement du formulaire "initial" qui contient le ElementHost vide prend du temps à charger au départ, mais cette fois ci le formulaire qui contient vraiment un contrôle WPF s'affiche instantanément, et sans bizarreries visuelles.

D'un point de vue plus technique, il semblerait que l'initialisation de WPF se fait lors de la création du premier ElementHost de l'application, puis se désinitialise lors de la fermeture du dernier ElementHost de l'application. Une petite analyse par réflector ne m'a pas montré l'existence d'une méthode "InitializeAndKeepWPFInitialized()", et il s'agit très probablement d'instancier un type de WPF pour initialiser proprement le tout... Mais créer une instance d'un ElementHost est amplement suffisant !

This post is available in english.

Il n'y pas très longtemps, je travaillais sur un problème d'un client qui avait une exception inhabituelle levée par les sockets dans un client WCF, lui même se connectant à un service WCF hebergé dans un IIS6.

Toujours avec moi ? :) Si vous avez un peu plus de temps pour lire, voici quelques détails à propos de ce problème...

Le déploiement est assez simple : Un client WCF qui envoie un "Stream" vers un service WCF pour lequel le "transferMode" est "Streamed". Cela permet de transférer un important volume d'information en utilisant du "vrai" streaming, ce qui veut dire que le client va écrire dans une instance de System.IO.Stream, et dans le même temps, le serveur lis de son coté dans un autre System.IO.Stream. Les données n'ont pas besoin d'être transférées d'un seul coup pour être traitées par le serveur, comme dans une communication SOAP classique. J'utilise pour cela des deux cotés le basicHttpBinding.

Le problème surviens lorsque plus de 15000 requêtes de transfert de "Stream" ont été effectuées, et l'exception suivante est levée :

System.ServiceModel.CommunicationException: Could not connect to http://server/streamtest/StreamServiceTest.Service1.svc.
TCP error code 10048: Only one usage of each socket address (protocol/network address/port) is normally permitted 10.0.0.1:80. 
---> System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted 10.0.0.1:80

En revanche, ce qui est inhabituel, c'est que l'exception est levée coté client et non coté serveur !

Après quelques netstat -an, j'ai trouvé un nombre impressionnant de sockets qui étaient en attente avec l'état suivant :

TCP    the.client:50819     the.server:80          TIME_WAIT

Il y avait quelque chose comme 15000 lignes comme celles la, avec des nombres s'incrémentant pour le port local. Cela a provoqué une pénurie de ports TCP entrants, d'où l'erreur reportée par les sockets. Cet état est cependant normal, et c'est un état attendu, mais il est plus communément trouvé sur un serveur et bien moins sur un client.

Cela ne pourrait vouloir dire qu'une chose, considérant que IIS6.0 est compatible HTTP/1.1: WCF demande que la connexion soit fermée à la fin d'un transfert "Streamed", alors qu'on pourrait penser qu'une connection en mode KeepAlive serait utilisée.

Wireshark étant mon ami, j'ai commencé à analyser le dialogue entre IIS6 et mon application cliente :

POST /streamtest/StreamServiceTest.Service1.svc HTTP/1.1
MIME-Version: 1.0
Content-Type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:41d2cf74-aaa6-4a80-a6c4-0ec37692a437+id=1";start-info="text/xml"
SOAPAction: "http://tempuri.org/IService1/Operation1"
Host: the.server
Transfer-Encoding: chunked
Expect: 100-continue
Connection: Keep-Alive

Ce qui veut dire qu'en fait, le client WCF demande bien que la connexion reste ouverte, contrairement à ce que les sockets fermés laissent penser. Le serveur répond ceci :

HTTP/1.1 100 Continue

Le transfert en mode stream s'opère, puis le client reçoit la réponse SOAP, puis ceci :

HTTP/1.1 200 OK
Date: Sat, 11 Jul 2009 01:40:16 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Connection: close
MIME-Version: 1.0
Transfer-Encoding: chunked
Cache-Control: private

Cela veut dire que c'est IIS6.0 ou le handler WCF qui force la fermeture de la connexion sur cette dernière réponse. La non plus, cette réponse n'est en soi pas anormale, puisque le KeepAlive peut être ignoré par le serveur et fermer la connexion malgré tout.

Le plus étrange dans tout cela, et vraiment à tout hazard, j'ai tenté de désactiver l'option KeepAlive du site web IIS6.0... Et à partir de ce moment la, toutes les connexions se sont fermées proprement sur le client !

Après une petite analyse du dialogue entre le client et le serveur, j'ai noté deux différences entre les deux états du KeepAlive :

1. Le contenu de la dernière réponse HTTP du serveur est composé de deux en-têtes "Connection: close", ce qui pourrait vouloir dire un par le handler WCF et un autre par IIS. Je ne suis pas certain que la répétition des headers soit interdite dans la RFC. Il faudra que je la relise pour en être certain.
2. Il semblerait que l'ordre des FIN/ACK, ACK est différent sur la fermeture de la connexion TCP, mais je ne suis pas certain de l'impact. Le client et le serveur envoient des paquets FIN de l'autre coté, ce qui est probablement le résultat d'un Socket.Close de chaque coté. Le problème vient peut-être de la.
   

Mais par la suite j'ai trouvé quelque chose de plus intéressant : Tout fonctionne avec IIS7 ! Et encore mieux, le statut KeepAlive est pris en compte par le serveur. Cela veut évidemment dire que le service web est bien plus performant avec IIS7 qu'il ne l'est avec IIS6, puisqu'une seule connexion TCP est ouverte pour les 15000 appels, ce qui est plutôt bon. Dommage que mon client ne puisse pas passer à IIS7 pour le moment...

Il semble également que WCF ne se comporte pas de la même manière avec IIS7 qu'avec IIS6, puisqu'au niveau TCP, il n'y a que le client qui termine la connexion en envoyant un TCP/FIN alors même que le KeepAlive serveur est désactivé.

Je vais probablement poster ce problème sur Microsoft Connect sous peu, mais je ne sais pas exactement ou se situe la source du problème, soit IIS6, le client WCF ou le handler serveur WCF. Dans tous les cas, il y a vraiment un problème.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 

    private static MethodInfo GetTaggedMethod(MethodInfo info)
    {
        MethodInfo ret = null;

        do
        {
            var attr = info.GetCustomAttributes(typeof(MyAttribute), false) as MyAttribute[];

            if (attr.Length != 0)
                return info;

            ret = info;

            info = info.GetBaseDefinition();
        }
        while (ret != info);

        return null;
    }

1
2
3
4
5
6
7
8
9
10
11
 

    public static class Extensions
    {
        public static IEnumerable<T> Traverse<T>(this T source, Func<T, T> next)
        {
            while (source != null)
            {
                yield return source;
                source = next(source);
            }
        }
    }

1
2
3
 

   var methodInfo = typeof(Dummy).GetMethod("Foo");

   IEnumerable<MethodInfo> methods = methodInfo.Traverse(m => m != m.GetBaseDefinition() ? m.GetBaseDefinition() : null);

1
2
3
4
5
6
7
8
9
 

    private static MethodInfo GetTaggedMethod(MethodInfo info)
    {
        var methods = from m in methodInfo.Traverse(m => m != m.GetBaseDefinition() ? m.GetBaseDefinition() : null)
                      let attributes = m.GetCustomAttributes(typeof(MyAttribute), false)
                      where attributes.Length != 0
                      select m;

        return methods.FirstOrDefault();
    }

Un détour par F#

1
2
3
4
5
6
 

    let rec traverse(m, n) =
       let next = n(m)
       if next = null then
           [m]
       else
           [m] @ traverse(next, n)

1
2
3
4
 

    let testMethod = typeof<Dummy>.GetMethod("Foo")

    for m in  traverse(testMethod, fun x -> if x = x.GetBaseDefinition() then null else x.GetBaseDefinition()) do
       Printf.printfn "%s.%s" m.DeclaringType.Name m.Name

1
2
3
4
5
6
7
8
9
 

    let rec traverse(m, n) =
       seq {
           let next = n(m)
           if next = null then
               yield m
           else
               yield m
               yield! traverse(next, n)
       }

• Une VM ne peut être détachée que si elle est en mode "Saved" ou "Stopped".
• Il n'est pas nécessaire d'arrêter le service Hyper-V, toutes les modifications sont détectées en live par Hyper-V.
  
• Une VM ne peux être importée que si elle comporte au moins un disque dur sur le controlleur IDE 0.
• Tous les fichiers de la VM doivent être sous la même racine, HDD et Snapshots.
• Tous les fichiers qui sont modifiés sont sauvegardés à coté des originaux, les fichiers de données ne sont pas modifiés, ni déplacés.
  
• .NET 3.5 doit être installé.
  

Extension TryWith

Extension Maybe

Pollution ?

• Le debugging d'une solution Web avec Webdev.Webserver.exe, et VS2008 crash en cours de debug. (Terminer le process ne suffit pas)
• Le redémarrage de VS2008, puis ouverture la même solution.
• Il se peut qu'à ce moment il ne soit plus possible de debugger avec VS2008, avec le message décrit plus haut. Un "Attach to Process" ne fonctionnera pas mieux.

Utiliser Umbrella

Voyons un exemple simple :

Enumerable
    .Range(20, 30)
    .ForEach(
       (index, value) => "Value #{0}={1}".InvariantCultureFormat(index, value)
    );

Comme vous pouvez le voir, utiliser Umbrella requiert très souvent l'emploi des lambda expressions. Cet exemple est une réponse à la question : "Comment avoir l'index d'une valeur énumerée dans un foreach ?" 

Vous pouvez bien entendu écrire du code qui fait exactement cela, mais vous auriez à créer une liste temporaire pour stocker les éléments à enlever, puis les enlever de la collection.

Il y a aussi une extension de IDictionary<> qui simplifie l'utilisation de TryGetValue, pour laquelle il est nécessaire de spécifier un argument "out", ce qui est particulièrement agaçant à écrire. Umbrella fourni une méthode nommée GetValueOrDefault qui donne soit la valeur associée à la clé, soit default(TValue) si la clé n'est pas trouvée.

L'extension Action.ToDisposable()

Extension Points

This post is also available in English here.

J'ai mis à jour mon Site Web de recherche des arrêts de bus de Montréal pour qu'il fonctionne un peu mieux sur un iPhone (Thanks, Mr Sanx).

Maintenant, les prochains horaires de bus sont un peu plus lisibles, et les anciens horaires sont plus faciles à éliminer visuellement.

Il y a aussi d'autres fonctionnalités en préparation, que j'ajouterais prochainement :)

La géolocalisation sur iPhone serait un plus puisque malheureusement Google Gears n'est pas disponible sur iPhone. Il semblerait qu'il y ai une sorte d'extension nommée weblocate:// qui puisse faire cela pour une application web, mais çà semble assez fumeux...

Quoi qu'il en soit, vous pouvez visiter le site depuis Windows Mobile, un iPhone, ou depuis un ordinateur de bureau à cette adresse :

http://jaylee.org/stm

Voici un exemple de ce que le site présente :

La premiere possibilité était hors de question dans mon cas, déplacer à nouveau le disque aurait été une perte de temps.

Cela m'a donc laissé l'option de montage du registry hive. Voici comment s'y prendre :

• Utiliser une autre VM sous windows pour monter le VHD, afin de pouvoir accéder au fichier hive SYSTEM.
• Utiliser regedit pour charger le fichier hive SYSTEM situé dans le répertoire System32\config\system et le placer dans HKLM/temp
• Modifier le ficher reg de la KB en replaçant toutes les références à "SYSTEM\CurrentControlSet" par "temp\ControlSet001", l'importer pour mettre à jour la configuration de démarrage par défaut,
• Modifier une nouvelle fois le fichier reg pour remplacer toutes les références à "SYSTEM\CurrentControlSet" par "temp\ControlSet002", pour modifier cette fois ci la "Derniere bonne configuration", juste au cas où.
• Décharger le fichier hive,
• Arreter la VM courante,
• Démarrer la nouvelle VM avec le VHD fixé et voilà !
  

This post is available in English here.

Avec le site web de Recherche des Arrêts de Bus de Montréal, afin d'utiliser Google Maps efficacement, il est impératif de laisser le browser client récupérer l'image par lui même. L'API de Google ne laisse pas une seule et même clé récupérer un grand nombre de cartes pour un même hôte, donc rediriger l'image depuis mon site n'est pas une option.

Je voulais donc avoir une URL générée en javascript pour pouvoir utiliser la largeur du corps HTML pour l'intégrer dans la requête vers Google Maps. J'ai donc créé un petit javascript qui construit une URL et l'assigne à l'attribut SRC de l'élément IMG qui va contenir la carte Google.

Et bien, cela semble simple mais pas tant que ça... L'élément IMG récupère bien l'image, mais sa taille n'est pas mise à jour avec celle de la nouvelle image. Dans mon cas, je place l'image dans un élément TABLE, la taille est donc celle par défaut pour une cellule.

Pour corriger cela, j'ai donc du assigner la hauteur et largeur de l'élément IMG, pour lui donner la bonne taille.

Pocket IE supporte minimalement le scripting, mais il est quelque peu évident que c'est un ajout complexe au moteur HTML... Allons Microsoft ! Vous pouvez faire mieux que ça ! Regardez ce qu'Opera a fait...