Return-Path: 
 <dev-return-57756-apmail-struts-dev-archive=struts.apache.org@struts.apache.org>
Delivered-To: apmail-struts-dev-archive@www.apache.org
Received: (qmail 68450 invoked from network); 21 May 2008 17:16:01 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 21 May 2008 17:16:01 -0000
Received: (qmail 30673 invoked by uid 500); 21 May 2008 17:16:01 -0000
Delivered-To: apmail-struts-dev-archive@struts.apache.org
Received: (qmail 30347 invoked by uid 500); 21 May 2008 17:15:59 -0000
Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@struts.apache.org>
List-Help: <mailto:dev-help@struts.apache.org>
List-Post: <mailto:dev@struts.apache.org>
List-Id: "Struts Developers List" <dev.struts.apache.org>
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Delivered-To: mailing list dev@struts.apache.org
Received: (qmail 30333 invoked by uid 99); 21 May 2008 17:15:59 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 10:15:59 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [213.208.226.13] (HELO charybdis.imc.nl) (213.208.226.13)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 17:15:13 +0000
X-IronPort-AV: E=Sophos;i="4.27,521,1204498800";
   d="scan'208";a="14574457"
Received: from smtp.nl.imc.local (HELO proxy02.nl.imc.local)
 ([192.168.144.31])
  by charybdis.nl.imc.local with ESMTP; 21 May 2008 19:15:26 +0200
Received: from [192.168.180.51] (helen.nl.imc.local [192.168.180.51])
	by proxy02.nl.imc.local (Postfix) with ESMTP id 60CA617700
	for <dev@struts.apache.org>; Wed, 21 May 2008 19:15:26 +0200 (CEST)
Message-ID: <483458AD.9020801@imc.nl>
Date: Wed, 21 May 2008 19:15:25 +0200
From: Giovanni Azua <giaz@imc.nl>
User-Agent: Thunderbird 1.5.0.7 (X11/20061008)
MIME-Version: 1.0
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: S2 2.1.1 race condition passing request params: bug?
References: <4833D3FB.2000501@imc.nl> <4833E054.20405@imc.nl>
In-Reply-To: <4833E054.20405@imc.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

hi,

The race-condition happens only because my simulation process uses the 
execAndWait interceptor:

<action name="SimulationRun" 
class="com.sag.optimizer.ui.web.action.simulation.SimulationRunAction">
 <interceptor-ref name="defaultStack"/>
 <interceptor-ref name="execAndWait">
   <param name="delay">1000</param>
   <param name="delaySleepInterval">1000</param>
 </interceptor-ref>
 <result name="wait" type="tiles">webui.simulationWait</result>
 <result name="success" type="tiles">webui.simulationReport</result>
 <result name="input" type="tiles">${ type.equals('COVARIANT') ? 
'webui.formCovSimulation' : 'webui.formInvSimulation' }</result>
 <result name="error" type="tiles">webui.requestFailed</result>
</action>       

When I change and use the default stack then I can not reproduce the 
race-condition issue anymore.

I am entering a new ticket for this maybe also another one to review the 
code at risk of race conditions using Calendar.getInstance and 
SimpleDateFormat singletons.

regards,
Giovanni

Giovanni Azua wrote:
> hi,
>
> I found XWorkBasicConverter.java is making thread-unsafe use of the
> mutable Calendar and SimpleDateFormat singletons, this could explain the
> race-condition issue.
>
> I am trying to debug it now ...
>
> regards,
> Giovanni
>
> Giovanni Azua wrote:
>   
>> hi,
>>
>> I found in the S2 2.1.1 test build the following scenario that seems to
>> be a bug, please confirm and I will enter a new ticket for it.
>>
>> I have a JSP page that allows the user to run simulations. This page
>> includes among others two datetimepicker fields "beginDate" and "endDate".
>>
>> It is a requirement that the user should be allowed to open e.g. five
>> firefox browser views and execute simultaneously five simulations. The
>> problem is that if the user submits two simulations simultaneously
>> enough the parameters of one request end up being assigned to the other
>> request too meaning there is a race condition somewhere before the
>> parameter gets assigned to the Action.
>>
>> Possible reasons for this:
>>
>> - a Stateful thread-unsafe interceptor
>> - dojo?
>>
>> I would appreciate any directions on this.
>>
>> best regards,
>> Giovanni
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>   


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