Woodstox

Performance issue with creating readers

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.1.2
  • Fix Version/s: 4.1.4
  • Labels:
    None
  • Number of attachments :
    0

Description

I have a particular case where we end up calling WstxOutputFactory.createXMLStreamWriter on hundreds of threads while processing a bunch of tiny xml docs. However, I'm seeing a lot of those threads blocking in:

   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.util.Hashtable.get(Hashtable.java:356)
        - waiting to lock <0x0000000780020618> (a java.util.Properties)
        at java.util.Properties.getProperty(Properties.java:951)
        at java.lang.System.getProperty(System.java:709)
        at java.lang.Boolean.getBoolean(Boolean.java:238)
        at com.ctc.wstx.api.CommonConfig.returnNullForDefaultNamespace(CommonConfig.java:203)
        at com.ctc.wstx.api.CommonConfig.getStdProperty(CommonConfig.java:240)
        at com.ctc.wstx.api.CommonConfig.getProperty(CommonConfig.java:110)
        at com.ctc.wstx.sw.BaseStreamWriter.getProperty(BaseStreamWriter.java:283)
        at com.ctc.wstx.sw.BaseStreamWriter.<init>(BaseStreamWriter.java:231)
        at com.ctc.wstx.sw.TypedStreamWriter.<init>(TypedStreamWriter.java:58)
        at com.ctc.wstx.sw.BaseNsStreamWriter.<init>(BaseNsStreamWriter.java:119)
        at com.ctc.wstx.sw.SimpleNsStreamWriter.<init>(SimpleNsStreamWriter.java:51)
        at com.ctc.wstx.stax.WstxOutputFactory.createSW(WstxOutputFactory.java:300)
        at com.ctc.wstx.stax.WstxOutputFactory.createSW(WstxOutputFactory.java:288)
        at com.ctc.wstx.stax.WstxOutputFactory.createXMLStreamWriter(WstxOutputFactory.java:134)

I'm wondering if that system property could be read once up front. Alternatively, allow setting that property on the factory so that I can do that up front.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tatu Saloranta added a comment -

Ouch. This is due to WSTX-270 – I did not quite realize that it checks System properties, which is Bad with capital B (IMO), for multiple reasons, performance being one.
Should have caught that one.

Need to figure out what is the best way to resolve this; I don't want this performance hit on per-serialization basis.

Maybe it could be as simple as just doing it once for factory...

Show
Tatu Saloranta added a comment - Ouch. This is due to WSTX-270 – I did not quite realize that it checks System properties, which is Bad with capital B (IMO), for multiple reasons, performance being one. Should have caught that one. Need to figure out what is the best way to resolve this; I don't want this performance hit on per-serialization basis. Maybe it could be as simple as just doing it once for factory...
Hide
Permalink
Daniel Kulp added a comment -


Note that the readers have the same issue, so it's also a per-parse issue as well.

Show
Daniel Kulp added a comment - Note that the readers have the same issue, so it's also a per-parse issue as well.
Hide
Permalink
Tatu Saloranta added a comment -

Yes, as it's in CommonConfig, shared between parse and generation sides.
I should have read the patch with more thought: even with cleanup it's a mess (I put constant in wrong place myself), and inconsistent with other settings, since Woodstox does not really use sysprops for anything else beyond Stax-api-handled factory locating.

Show
Tatu Saloranta added a comment - Yes, as it's in CommonConfig, shared between parse and generation sides. I should have read the patch with more thought: even with cleanup it's a mess (I put constant in wrong place myself), and inconsistent with other settings, since Woodstox does not really use sysprops for anything else beyond Stax-api-handled factory locating.
Hide
Permalink
Tatu Saloranta added a comment -

Fixed, so that cost of System property lookup is only incurred when factory is constructed. This means that system property changes take effect for new factories.

I also made property settable, so that one does not have to use System property (in fact, the new way is preferred way).

Will see when 4.1.4 should be released; given drastic effects of this, may need to release with just this one fix.

Show
Tatu Saloranta added a comment - Fixed, so that cost of System property lookup is only incurred when factory is constructed. This means that system property changes take effect for new factories. I also made property settable, so that one does not have to use System property (in fact, the new way is preferred way). Will see when 4.1.4 should be released; given drastic effects of this, may need to release with just this one fix.
Tatu Saloranta made changes -
Field Original Value New Value
Resolution Fixed [ 1 ]
Fix Version/s 4.1.4 [ 18680 ]
Status Open [ 1 ] Resolved [ 5 ]

People

  • Assignee:
    Tatu Saloranta
    Reporter:
    Daniel Kulp
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: