Ich beobachte ein ungewöhnliches Verhalten und würde gerne verstehen, was passiert.
Stellen Sie sich eine einfache Einrichtung vor.
Zuerst habe ich eine statuslose Bohne, die einfach etwas zurückgibt:
%Vor%Dann habe ich eine andere statuslose Bean, die etwas verarbeitet
%Vor%Dann habe ich eine einfache CDI-Bean, um die Prozessmethode aufzurufen.
Ergebnis:
Wenn ich die Methode process mehrmals nacheinander aufrufe, wird die Prozesszeit weiter erhöht:
Und es geht jedes Mal weiter, wenn die Methode aufgerufen wird.
Wie kann das erklärt werden?
Ich verwende Java JDK 1.7.0_25 und JBOSS EAP 6.1.
BEARBEITEN
Übrigens besteht die einzige Möglichkeit, die Verarbeitungszeit für die Methode zu 'zurücksetzen' darin, den Server neu zu starten.
Ich habe mit WildFly 8.1.0.Final getestet und bekomme Folgendes:
%Vor%Und dann stabilisiert es sich um 90ms.
Ich denke also, wir können davon ausgehen, dass das ursprüngliche Problem ein Bug in JBoss AS 7 war, der in WildFly 8.1 behoben wurde. Mehr als behoben haben sie sogar eine Optimierung eingeführt!
BEARBEITEN!
Ich entschuldige mich bei allen, ich habe eine falsche Diagnose gestellt. Dieser Fehler hat nichts mit der Version von JBoss zu tun, sondern wurde von JRebel verursacht.
Als ich Wildfly heruntergeladen habe, habe ich es nicht im Debug-Modus mit angehängtem JRebel Agent ausgeführt (was ich ständig mit EAP 6.1 gemacht habe). Wenn ich JBoss EAP 6.1 ohne JRebel starte, tritt das Problem nicht auf.
Ich habe mich an JRebel gewöhnt. Ich habe vergessen, dass ich es eingeschaltet hatte!
Ich werde ein Problem mit dem JRebel-Team ansprechen.
BEARBEITEN 2
Das JRebel-Team untersuchte und konnte den Defekt reproduzieren. Es wurde im nächtlichen Build behoben und wird in der nächsten Version behoben (fällig August / September 2014)
Können Sie den gleichen Test versuchen, aber erstellen Sie eine Schnittstelle SimpleService und aktuelle SimpleService wird etwas wie SimpleServiceImpl, die SimpleService implementieren wird.
Ich würde annehmen, dass cdi Magie benutzt, um EJB zu umhüllen.
Hmm .. oder eine andere Sache könnte versuchen, @EJB-Injektion statt @Inject