We forgot to point out that problem takes place in both GUI and non-GUI modes. Thanks
> -----Original Message----- > From: Vladimir Tsygankov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 26, 2004 7:08 PM > To: 'JMeter Users List' > Subject: RE: Regular expressions for some threads are calculated > incorrectly > > Hello, all. > It is an OLD problem. > There is a terrible problem: regular expression engine works incorrectly > (sometimes!!!) when a test has many threads. JMeter Version > 2_0_20040523. > > We see that again and again and it makes our more than 60 test scripts > useless. We already wrote about that in the bug > http://issues.apache.org/bugzilla/show_bug.cgi?id=29202 > but we are not sure anybody read it. > Our test is modelling work of 50 users (let them named c1-c50). > Every user logins to the server, opens its file (let them named > CFR1-CFR50) on it and enters some data. > The main problem - test works non stable. Sometimes it works fine, > another time - any users can not open its files. > Last time only c13 could not open its file CFR13. > We think regular expression engine (sometimes!!!) works incorrectly when > a test has many threads. > Short explanation. > Test script has 50 threads (one thread for every user). > To define the field of request 9 ContainerID we used the next regular > expression: > ${__regexFunction(<option value="(.*)" > >spb1,$1$,${__threadNum},,,refContainerID)}. > The part of page for finding is: > > <option value="373" >spb1 - CFR 10</option> > <option value="374" >spb1 - CFR 11</option> > <option value="375" >spb1 - CFR 12</option> > <option value="376" >spb1 - CFR 13</option> > <option value="377" >spb1 - CFR 14</option> > <option value="378" >spb1 - CFR 15</option> > > For all 50 threads except the thread 13 test worked fine. For the tread > 13 it found value 377 (belongs to the thread 14) instead of 376. > Requests for c13 and c14 looked like: > > c13:GET > http://test.athenium.com/teamthink/rqa1/teamthink?PageHandler=SelectCont > ainer.DashboardModuleSelect&FilterWhat=6&ContainerID=377&OpenContainer=+ > Open+&SessionID=B0oooUbBZiTSRTednpqjaFmUJKqbAEIATK2dfmcAfHjhhOFl2QLjklDS > VW > > c14:GET > http://test.athenium.com/teamthink/rqa1/teamthink?PageHandler=SelectCont > ainer.DashboardModuleSelect&FilterWhat=6&ContainerID=377&OpenContainer=+ > Open+&SessionID=IrjFj2RdATPJHQBdOiKiMfSJJKkgaVP0ocfIWMTaQpXeVblIWRe0FM > > We think it could take place due to incorrect using the function > regexFunction in many threads environments. > Could you please help us? > > Thanks in advance > > > > -----Original Message----- > > From: BAZLEY, Sebastian [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 10, 2004 9:59 PM > > To: 'JMeter Users List' > > Subject: RE: Regular expressions for some threads are calculated > incorrect > > ly > > > > Remember that .* is greedy, so your regex could match more than you > > expect. > > > > It would be safer to use value="(.*?)". > > > > I doubt that this will fix the problem, however, please try it and > see. > > > > == > > > > If it still fails in non-GUI mode, could you create a bugzilla entry > and > > upload a sample test plan please? > > > > [Attachments to the list often get lost or mangled, and are a nuisance > for > > users on slow connections] > > > > == > > > > Why should GUI and non-GUI mode be different? Perhaps: > > - non-GUI may be able to process threads faster and thus expose a > timing > > bug > > - GUI mode might cause some extra synchronisation that hides a timing > bug > > > > S. > > -----Original Message----- > > From: Vladimir Tsygankov [mailto:[EMAIL PROTECTED] > > Sent: 10 March 2004 17:30 > > To: 'JMeter Users List' > > Subject: Regular expressions for some threads are calculated > incorrectly > > > > > > Hello, colleagues, > > We think the next regular expression function > > ${__regexFunction(<option value="(.*)" > > >File,$1$,${__threadNum},,,refContainerID)} > > for various threads from time to time works incorrectly in non-GUI > > JMeter mode. It misses results for threads. > > We attached log files for cases of correct (Thread32-server > answer.txt, > > Thread32-correct request.txt) and incorrect (Thread33-server > answer.txt, > > Thread33-incorrect request.txt) working. > > It should work the next way: > > for thread 32: ContainerID=47 > > for thread 33: ContainerID=48 (really ContainerID=49 - it is for > another > > thread!) > > > > Notes. 1. It happens occasionally (for any thread. Sometimes it > doesn't > > happen at all). > > 2. It seems to depend on number of threads (it doesn't take place for > a > > few threads). We were > > testing for about 100 threads (users) > > 3. Perhaps it connected with incorrect function "__threadNum" which is > > included in regexFunction. > > 4. We tried some times under JMeter with GUI and it worked fine. > > 5. We used JMeter (jakarta-jmeter-20040215). > > > > Thanks in advance, > > Vladimir > > > > > > > ________________________________________________________________________ > __ > > _ > > > > This e-mail and the documents attached are confidential and intended > > solely > > for the addressee; it may also be privileged. If you receive this > e-mail > > in > > error, please notify the sender immediately and destroy it. As its > > integrity > > cannot be secured on the Internet, the Atos Origin group liability > cannot > > be > > triggered for the message content. Although the sender endeavours to > > maintain > > a computer virus-free network, the sender does not warrant that this > > transmission is virus-free and will not be liable for any damages > > resulting > > from any virus transmitted. > > > ________________________________________________________________________ > __ > > _ > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
