1. Startseite
  2. Support
Artikel - CS275805

Windchill PDMLink Background MethodServer JVM startet die vollständige Garbage Collection (GC) und wird jedes Mal beendet, wenn ein besonders großer Interferenzerkennungsjob (CLASH) verarbeitet wird.

Geändert: 08-Apr-2025   


Hinweis: Dieser Artikel wurde mit Hilfe maschineller Übersetzungssoftware übersetzt, um Ihnen die Arbeit zu erleichtern. Bitte beachten Sie, dass PTC keine Gewähr für die Zuverlässigkeit oder Lesbarkeit des Inhalts der Übersetzung übernimmt. Klicken Sie hier, um die englische Originalversion des Artikels zu lesen. Weitere Informationen zur maschinellen Übersetzung finden Sie hier.
Vielen Dank für den Hinweis. Wir werden die Übersetzung so bald wie möglich überprüfen.

Betrifft

  • Windchill PDMLink 10.0 to 11.1
  • Creo View Adapters 1.0 to 4.2
  • Windchill Visualization Services (WVS)
  • Windchill Interference Management Services (Batch Interference Detection)
  • Interference Engine (PVSCLASH)

Beschreibung

    • Der Versuch, eine sehr große Interferenzerkennungsabfrage zu verarbeiten, führt dazu, dass der Background MethodServer, der die CLASH-Warteschlangen verarbeitet, beendet wird, da seiner Java Virtual Machine (JVM) der Heap-Speicher ausgeht.
    • Die JVM gibt zunächst Warnungen aus, die darauf hinweisen, dass sie in den Zustand „Wenig Speicher“ wechselt:
    WARN [Service-Thread] wt.method.MemoryUsageRedirectStrategy – Wechselt in einen Zustand mit wenig Arbeitsspeicher
    . . .
    WARNUNG [Service-Thread] wt.jmx.notif.memory – Zeit=2017-11-10 15:15:46.401 +0100, Name=MemoryNotifier, SourceObjectName=com.ptc:wt.subsystem=Monitors,wt.monitorType=Memory, Klasse=Klasse javax.management.Notification, Typ=java.management.memory.collection.threshold.exceeded, Benutzerdaten=[Anzahl=17,Poolname=PS Old Gen,Nutzung=[committed=4294967296,Init=4294967296,Max=4294967296,Verwendet=4294493016]], Nachricht=Speichernutzung überschreitet Schwellenwert für Sammlungsnutzung , JVM-Name=18108@<id>, Schwellenwert
    . . .
    • Bevor die JVM endgültig beendet wird, führt sie eine vollständige Garbage Collection (GC) durch und beginnt mit der Ausgabe periodischer Stacktraces.
    • Diese Stapelüberwachungen zeigen, dass der Stapel des Clash Queue Polling Threads nach und nach den gesamten verfügbaren Speicher (zugewiesene Bytes) verbraucht:
    " PublisherQueueCLASH1.PollingThread " Id=135 prio=5 AUSFÜHRBAR
    Blockiert (Anzahl): 49; Gewartet (Anzahl): 54
    CPU-Nanos: 46437732600; Benutzer-Nanos: 40670734600; Zugewiesene Bytes: 5253773176
    Methodenkontext: 2z5syc;j9ttcvhq;18108;wm0cs4;3589; DB-Sitzung: 1308
    bei java.io.FileInputStream.readBytes (native Methode)
    bei java.io.FileInputStream.read(FileInputStream.java:272)
    bei org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read (Unbekannte Quelle)
    bei org.apache.xerces.impl.io.UTF8Reader.read (Unbekannte Quelle)
    bei org.apache.xerces.impl.XMLEntityScanner.load (Unbekannte Quelle)
    bei org.apache.xerces.impl.XMLEntityScanner.scanContent (Unbekannte Quelle)
    bei org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent (Unbekannte Quelle)
    bei org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch (Unbekannte Quelle)
    bei org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (Unbekannte Quelle)
    bei org.apache.xerces.parsers.XML11Configuration.parse (Unbekannte Quelle)
    bei org.apache.xerces.parsers.XML11Configuration.parse (Unbekannte Quelle)
    bei org.apache.xerces.parsers.XMLParser.parse (Unbekannte Quelle)
    bei org.apache.xerces.parsers.DOMParser.parse (Unbekannte Quelle)
    bei org.apache.xerces.jaxp.DocumentBuilderImpl.parse (Unbekannte Quelle)
    bei javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
    bei wt.util.xml.NonValidatingXML4jAdapter.createDOMDocument(NonValidatingXML4jAdapter.java:147)
    bei com.ptc.wvs.common.util.SimpleXml.getDocument(SimpleXml.java:210)
    bei com.ptc.wvs.common.util.SimpleXml.getDocument(SimpleXml.java:188)
    bei com.ptc.wvs.server.publish.InterferenceDetectionHelper.processInterferenceReport ( InterferenceDetectionHelper.java:483 )
    bei com.ptc.wvs.server.publish.CadConvertCLASH.storeComponentRepresentation(CadConvertCLASH.java:360)
    bei com.ptc.wvs.server.publish.ClashJob.executeClashJob(ClashJob.java:310)
    bei com.ptc.wvs.server.publish.ClashJob.processJob(ClashJob.java:125)
    bei com.ptc.wvs.server.publish.WVSProcessingJob.doMyJob(WVSProcessingJob.java:549)
    bei com.ptc.wvs.server.publish.WVSProcessingJob.doJobInternal(WVSProcessingJob.java:510)
    bei com.ptc.wvs.server.publish.WVSProcessingJob.doJob(WVSProcessingJob.java:480)
    bei sun.reflect.NativeMethodAccessorImpl.invoke0 (native Methode)
    bei sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    bei sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    bei java.lang.reflect.Method.invoke(Method.java:606)
    bei wt.queue.QueueEntry.execute(QueueEntry.java:224)
    bei wt.queue.ProcessingQueue.execEntry(ProcessingQueue.java:285)
    bei wt.queue.ProcessingQueue.execEntries(ProcessingQueue.java:901)
    bei wt.queue.PollingQueueThread.run(PollingQueueThread.java:99)
    • Die JVM wird letztendlich und abrupt ohne weitere Meldungen beendet
    • WVS BGM stürzt jedes Mal mit vollem GC ab, wenn wir einen Interferenzerkennungsauftrag für eine große Baugruppe übermitteln
    Diese PDF-Version von Artikel 275805 ist möglicherweise veraltet. Aktuelle Version CS275805