OxygenXML 15 VERY slow to recover after bulk XSLT transform

[sarcanon]

I am working on a project with almost 3,000 XML documents that I do several bulk XSLT transformations (into HTML pages) on a regular basis (3-4 times daily). This was taking more time I wanted to wait, and therefore decided to upgrade to a faster computer to help speed up these operations. Well, I succeeded in one respect, in that the XSLT transformations on my new machine are 2-3x faster than my old one. The problem is, that upon completion of the bulk operation, the Oxygen user interface becomes completely unresponsive for several minutes (i.e., 5-10). The amount of time of this "pause" in Oxygen's recovery means that my transformations now take almost as long as my old slow machine! Very frustrating.

By "non-responsive", I mean Oxygen does not respond to any mouse or keyboard commands. If I look in the Task Manager, I can see that it is continuing to churn away during this pause, fully maxing out one of the CPU's 8 cores. But the message bar at the bottom of Oxygen's window shows that the operation was completed before this "freeze-up" occurs. If I minimize the application, and then restore its window, the window is solid black. After the freeze, Oxygen appears to work normally again, seemingly unaware of its fit of narcolepsy. Any ideas why this is happening and how I can prevent it?

I am running Oxygen XML 15.0 build 2013071613. This is on Windows 7 (64-bit). The new machine is an Intel Core i7-4770 3.4 gHz CPU with 16GB of RAM, with the Oxygen application and all documents residing on a solid-state disk.

My old machine, albeit slower to complete these operations, has no such recovery issues. FWIW, that machine also runs the same version of Oxygen under Windows 7(bit-64) with AMD Phenom II X4 945 CPU (3 gHz) with 8GB RAM running with spinning 5400 rpm HD.

Thank you.

[adrian]

Hello,

Are there any result panels open at the bottom of the editor after Oxygen "recovers consciousness"?

It's sometimes possible after batch operations that one of the result panels has so many items queued to be displayed in the list, that it makes the GUI become unresponsive until all are processed. Depending on the configuration of the transformation scenario, it's also possible that there are many result panels (e.g. one per transformation) and this can have a similar result.

The fact that the window remains black after a minimize+restore usually means that the AWT thread (handles the application GUI repaint) is still busy doing post-operation work.

Regards,
Adrian

[jloneto]

Hi,
I have a very similar problem with the lastest version of Oxygen Editor (23.1 build 2021082307) 64 bit under Windows 10 Pro 64 bit (french).
I only noticed this problem processing XML files encoded in UTF-8 and containing characters from both Left-to-Right (latin, french, german, greek...) and Right-to-Left (arabic, hebrew...) alphabets;
I hope this could help to investigate the problem.
Best regards,
Jean-Louis

[adrian]

Hello Jean-Louis,

It's best to start a new topic when investigating issues for a far newer version. The original topic was started in 2013 for Oxygen v15.

I only noticed this problem processing XML files encoded in UTF-8 and containing characters from both Left-to-Right (latin, french, german, greek...) and Right-to-Left (arabic, hebrew...) alphabets;

In your case it's most likely a special characters (BiDi) support issue. The special characters (BiDi) support is usually triggered for RTL scripts and some special combining characters.
In the transformation scenario configuration, in the Output tab, clear all the boxes from the "Show in results view as" (XML, SVG, HTML).

Regards,
Adrian