Mein Dienst verwendet Camel, um Nachrichten aus mehreren Warteschlangen zu lesen. Nachdem ich kürzlich den JDK in Java 17 (und eine Reihe von Abhängigkeiten für die Kompatibilität) migriert habe, habe ich ein Speicherleck gesehen, und ich weiß nicht, dass die beiden verwandt sind. Ich vermute, der Code sammelt derzeit keinen Müll und mein JMSendPoint -Schnittstellenobjekt benötigt eine Kombination aus Stopp, Herunterfahren und Close, die aufgerufen werden. Gegenwärtig rufen wir nirgendwo nirgendwo an, und wir verwenden auch keinen Try-mit-Ressourcen-Block. Ein Senior -Ingenieur, mit dem ich zusammenarbeite, glaubt, dass die Müllsammlung hinter den Kulissen von Frühling oder Kamel durchgeführt wird. Im Folgenden finden Sie relevante Ausschnitte von Beispielcode, ähnlich wie wir es implementiert haben. MyMethod wird mit der Bean -Methode auf einer Route aufgerufen. Wir haben Onexception in der Route implementiert, aber wir machen dort auch keine explizite Müllsammlung. Habe ich recht, dass wir explizit Müll sammeln müssen? Irgendwelche anderen Diagnosen? < /P>
Code: Select all
import org.apache.camel.ConsumerTemplate;
import org.apache.camel.Exchange;
import org.apache.camel.component.jms.JmsComponent;
import org.apache.camel.component.jms.JmsEndpoint;
import org.springframework.beans.factory.annotation.Autowired;
...
public class MyClass {
private JmsComponent jmsComponent;
@Autowired
ConsumerTemplate consumerTemplate;
...
public void myMethod(Exchange exchange) {
//obviously-fake values below to protect the guilty
JmsEndpoint jmsEndpoint = new JmsEndpoint("uri", jmsComponent, "destinationName", false, jmsConfiguration);
Exchange newExchange = null;
...//logic for waiting, don't ask
newExchange = consumer.receiveNoWait(jmsEndpoint);
//something like the following?
//jmsEndpoint.close();
...
Mobile version