RAP et les Jobs – Part 2

Nous avons vu dans le billet précédent qu’il était important de bien redéfinir certaines méthodes de la classe Job afin d’éviter les fuites mémoires. Cependant, après avoir appliqué ces préconisations, il est facile de constater que les Jobs exécutés ne sont pas garbage collectés tant que la session de l’utilisateur les ayant sollicités est active.

En effet, lors de chaque exécution, le JobManagerAdapter appelle la méthode bindToSession définie ci-dessous avec le Job en argument.

1. private void bindToSession( final Object keyToRemove ) {
2. ISessionStore session = RWT.getSessionStore();
3. HttpSessionBindingListener watchDog = new HttpSessionBindingListener() {
4. public void valueBound( final HttpSessionBindingEvent event ) {
5. }
6. public void valueUnbound( final HttpSessionBindingEvent event ) {
7. try {
8. handleWatchDog( keyToRemove );
9. } finally {
10. synchronized( lock ) {
11. jobs.remove( keyToRemove );
12. }
13. }
14. }
15. …
16. };
17. session.setAttribute( String.valueOf( watchDog.hashCode() ), watchDog );
18. }

Cette méthode place en session un objet possédant une référence directe sur le Job. Malheureusement, la valeur de la clé de stockage étant créée localement, il est ensuite incapable de le retirer. Autre conséquence, le code contenu dans valueUnbound, qui peut sembler important, ne sera jamais exécuté.
Pour contourner cette fuite mémoire, je n’ai pas trouvé d’autre moyen que de patcher le code de RAP. La solution proposée consiste à indiquer au Job la clé avec laquelle il sera mis en session lors du valueBound :

1. private void bindToSession( final Object keyToRemove ) {
2. ISessionStore session = RWT.getSessionStore();
3. HttpSessionBindingListener watchDog = new HttpSessionBindingListener() {
4. public void valueBound( final HttpSessionBindingEvent event ) {
5. /* START : Patch */
6. if (keyToRemove instanceof Job)
7. ((Job) keyToRemove).setProperty(new QualifiedName(null,
8. “watchDogKey”), String.valueOf(this.hashCode()));
9. /* END : Patch */
10. }
11. public void valueUnbound( final HttpSessionBindingEvent event ) {
12. try {
13. handleWatchDog( keyToRemove );
14. } finally {
15. synchronized( lock ) {
16. jobs.remove( keyToRemove );
17. }
18. }
19. }
20. …
21. };
22. session.setAttribute( String.valueOf( watchDog.hashCode() ), watchDog );
23. }

Puis de redéfinir le constructeur de notre classe de Job en ajoutant systématiquement un listener responsable de le retirer de la session à la fin de son exécution :

1. public MonJob(final String name)
2. {
3. super(name);
4. addJobChangeListener(new JobChangeAdapter()
5. {
6. @Override
7. public void done(final IJobChangeEvent event)
8. {
9. RWT.getSessionStore().removeAttribute(
10. String.valueOf(event.getJob().getProperty(new QualifiedName(null, “watchDogKey”))));
11. }
12. });
13. }

Vous pouvez suivre l’évolution de cette anomalie sur le bug-tracking du projet RAP à l’adresse suivante.