You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Erin Harris (JIRA)" <xa...@xml.apache.org> on 2006/09/12 15:44:22 UTC

[jira] Created: (XALANJ-2321) Multi-threading problem with AVTs

Multi-threading problem with AVTs
---------------------------------

                 Key: XALANJ-2321
                 URL: http://issues.apache.org/jira/browse/XALANJ-2321
             Project: XalanJ2
          Issue Type: Bug
          Components: Xalan
    Affects Versions: 2.6, 2.7
         Environment: multi-processor  systems
            Reporter: Erin Harris


The following code in AVT.java is causing problems for multi-threaded test cases:

  private final FastStringBuffer getBuffer(){
    if(USE_OBJECT_POOL){
       return StringBufferPool.get();
    }else if(m_cachedBuf == null){
       m_cachedBuf = new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
       return m_cachedBuf;
    }else if(m_cachedBuf.length() != 0){
      return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
    }else{
       return m_cachedBuf;
     }
  }

Because the same object node for the AVT is used by each thread, sometimes on one thread the buffer would be empty just as another thread is writing to it and thus both threads would write to the same buffer.  This caused problems for a customer that used <xsl:element name="{local-name()}">  a lot and were running on a multi-processor machine.

The suggested fix is to change the code to the following, and remove the m_cachedBuf field:

  private final FastStringBuffer getBuffer(){
    if(USE_OBJECT_POOL){
      return StringBufferPool.get();
    }else{
      return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
    }
  }


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org


[jira] Commented: (XALANJ-2321) Multi-threading problem with AVTs

Posted by "Rony Zoghby (JIRA)" <xa...@xml.apache.org>.
    [ https://issues.apache.org/jira/browse/XALANJ-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465450 ] 

Rony Zoghby commented on XALANJ-2321:
-------------------------------------

Hi,

Back in the stream!

We are still facing this issue and i was glad to see that it has been fixed.
We will try the patch and give you our feedback.

Thank you all !

> Multi-threading problem with AVTs
> ---------------------------------
>
>                 Key: XALANJ-2321
>                 URL: https://issues.apache.org/jira/browse/XALANJ-2321
>             Project: XalanJ2
>          Issue Type: Bug
>          Components: Xalan
>         Environment: multi-processor  systems
>            Reporter: Erin Harris
>             Fix For: 2.7.1
>
>         Attachments: AVT.patch
>
>
> The following code in AVT.java is causing problems for multi-threaded test cases:
>   private final FastStringBuffer getBuffer(){
>     if(USE_OBJECT_POOL){
>        return StringBufferPool.get();
>     }else if(m_cachedBuf == null){
>        m_cachedBuf = new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>        return m_cachedBuf;
>     }else if(m_cachedBuf.length() != 0){
>       return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>     }else{
>        return m_cachedBuf;
>      }
>   }
> Because the same object node for the AVT is used by each thread, sometimes on one thread the buffer would be empty just as another thread is writing to it and thus both threads would write to the same buffer.  This caused problems for a customer that used <xsl:element name="{local-name()}">  a lot and were running on a multi-processor machine.
> The suggested fix is to change the code to the following, and remove the m_cachedBuf field:
>   private final FastStringBuffer getBuffer(){
>     if(USE_OBJECT_POOL){
>       return StringBufferPool.get();
>     }else{
>       return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>     }
>   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org


[jira] Commented: (XALANJ-2321) Multi-threading problem with AVTs

Posted by "Brian Minchau (JIRA)" <xa...@xml.apache.org>.
    [ http://issues.apache.org/jira/browse/XALANJ-2321?page=comments#action_12442958 ] 
            
Brian Minchau commented on XALANJ-2321:
---------------------------------------

Per the JIRA triage meeting on Oct 16, 2005, Yash T. agreed to review the patch.

> Multi-threading problem with AVTs
> ---------------------------------
>
>                 Key: XALANJ-2321
>                 URL: http://issues.apache.org/jira/browse/XALANJ-2321
>             Project: XalanJ2
>          Issue Type: Bug
>          Components: Xalan
>         Environment: multi-processor  systems
>            Reporter: Erin Harris
>         Attachments: AVT.patch
>
>
> The following code in AVT.java is causing problems for multi-threaded test cases:
>   private final FastStringBuffer getBuffer(){
>     if(USE_OBJECT_POOL){
>        return StringBufferPool.get();
>     }else if(m_cachedBuf == null){
>        m_cachedBuf = new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>        return m_cachedBuf;
>     }else if(m_cachedBuf.length() != 0){
>       return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>     }else{
>        return m_cachedBuf;
>      }
>   }
> Because the same object node for the AVT is used by each thread, sometimes on one thread the buffer would be empty just as another thread is writing to it and thus both threads would write to the same buffer.  This caused problems for a customer that used <xsl:element name="{local-name()}">  a lot and were running on a multi-processor machine.
> The suggested fix is to change the code to the following, and remove the m_cachedBuf field:
>   private final FastStringBuffer getBuffer(){
>     if(USE_OBJECT_POOL){
>       return StringBufferPool.get();
>     }else{
>       return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>     }
>   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org


[jira] Resolved: (XALANJ-2321) Multi-threading problem with AVTs

Posted by "Brian Minchau (JIRA)" <xa...@xml.apache.org>.
     [ http://issues.apache.org/jira/browse/XALANJ-2321?page=all ]

Brian Minchau resolved XALANJ-2321.
-----------------------------------

    Fix Version/s: Latest Development Code
       Resolution: Fixed

I just applied the patch that Yash reviewed to the latest development code. .... done

> Multi-threading problem with AVTs
> ---------------------------------
>
>                 Key: XALANJ-2321
>                 URL: http://issues.apache.org/jira/browse/XALANJ-2321
>             Project: XalanJ2
>          Issue Type: Bug
>          Components: Xalan
>         Environment: multi-processor  systems
>            Reporter: Erin Harris
>             Fix For: Latest Development Code
>
>         Attachments: AVT.patch
>
>
> The following code in AVT.java is causing problems for multi-threaded test cases:
>   private final FastStringBuffer getBuffer(){
>     if(USE_OBJECT_POOL){
>        return StringBufferPool.get();
>     }else if(m_cachedBuf == null){
>        m_cachedBuf = new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>        return m_cachedBuf;
>     }else if(m_cachedBuf.length() != 0){
>       return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>     }else{
>        return m_cachedBuf;
>      }
>   }
> Because the same object node for the AVT is used by each thread, sometimes on one thread the buffer would be empty just as another thread is writing to it and thus both threads would write to the same buffer.  This caused problems for a customer that used <xsl:element name="{local-name()}">  a lot and were running on a multi-processor machine.
> The suggested fix is to change the code to the following, and remove the m_cachedBuf field:
>   private final FastStringBuffer getBuffer(){
>     if(USE_OBJECT_POOL){
>       return StringBufferPool.get();
>     }else{
>       return new FastStringBuffer(INIT_BUFFER_CHUNK_BITS);
>     }
>   }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org