OK, we've got a number of people in-house who are now having the aforementioned problem -- for now, i'm going to rip out selenium-grid (since I'm not using parallelization at the moment) and try direct-to- rc and see how that goes.
thanks guys, Jas. On May 26, 5:23 pm, Jason <[email protected]> wrote: > Thanks Haroon -- I've upgraded to selenium-grid-1.0.7 so we'll see how > that goes... > > Since upgrade, I've seen one hang so far (on another QA team-member's > box) with the following warning around the same time: > > [java] INFO: Garbage collecting unavailable RCs and stale > sessions... > [java] May 26, 2010 2:53:32 PM > org.apache.commons.httpclient.SimpleHttpConnectionManager > getConnectionWithTimeout > [java] WARNING: SimpleHttpConnectionManager being used > incorrectly. Be sure that HttpMethod.releaseConnection() is always > called and that only one thread > and/or method is using this connection manager at a time. > > However, I'm running on our daily build box to see how consistent it > is. > > If you have any thoughts on the releaseConnection(), I'd love to > hear... > > Jason > > On May 26, 1:57 am, Haroon Rasheed <[email protected]> wrote: > > > We had similar problems because in our CMS application it was taking a long > > time to setup the data for the tests and selenium browser was sitting idle > > which results in Selenium HUB looses connection with the RC and does not > > unregister it. > > > I would suggest you to upgrade to the latest version of selenium grid which > > is 1.0.7. You can set the self healing parameters at the following > > URL.http://selenium-grid.seleniumhq.org/configuring-and-tuning.html > > > <http://selenium-grid.seleniumhq.org/configuring-and-tuning.html>-Haroon > > > On 26 May 2010 01:02, Jason <[email protected]> wrote: > > > > Thanks! > > > > To clarify -- Jian: I'm not using any parallelization (any longer) in > > > tests, as it seems to be consistently problematic. In fact, I'm only > > > connecting to a single selenium server thru my hub. > > > > If you think it's most-likely a selenium hub timeout problem, I may > > > try to either modify the session timeout or remove the grid from the > > > equation entirely. > > > > As far as the session timeout goes, do you happen to know what i can > > > do to extend it? Although as I understand it, if a selenium server > > > session times out, the hub unregisters it. In my case, however, the > > > hub console shows this selenium server as still active, which seems > > > inconsistent with the 'timeout theory' Would this also be your > > > understanding? Do you happen to know where i can find the default > > > value for the session timeout? It does feel somewhat likely, as it > > > seems to occur around tests that run long periods of time without any > > > selenium server activity (we have a number of tests that do other non- > > > selenium activities for minutes at a stretch, then 'come back' to the > > > browser...) > > > > cheers, > > > Jason > > > > On May 25, 2:34 pm, Haroon Rasheed <[email protected]> wrote: > > > > We have had these kind of problems with Selenium Grid, where the HUB is > > > > locked and not communicating with the RC machine anymore. We suspect > > > > that > > > > this is due to the default timeout. If the Selenium RC session sits idle > > > for > > > > some time then Selenium HUB stops communicating with the Selenium RC > > > > instances. The new version of Selenium Grid solves this by providing > > > > self > > > > healing properties which users can use to override the default > > > > behaviour. > > > > > You can use the following URL to make a call to the HUB to un-register > > > the > > > > hanged RC sessions. > > > > http:// > > > > {selenium.hub}:{hub.port}/registration-manager/unregister?host={RC.host}&port=5556&environment=*iexplore > > > > > As Jian mentioned, we are planning to have native parallelisation in > > > > Tellurium which should improve things. > > > > > Cheers > > > > Haroon > > > > > On 25 May 2010 20:30, John <[email protected]> wrote: > > > > > > But to your questions, I would say that the test parallelism in 0.6.0 > > > > > is poor. > > > > > 0.7.0 is not any better. In 0.8.0, we will reconsider the whole > > > > > architecture to support that. > > > > > > If you don't call disconnectSeleniumServer(), the broswer will keep > > > > > open. > > > > > But once you shutdown selenium server, all the browser sessions > > > > > associated > > > > > with it will be forced to close. Would you be able to shut down > > > > > Selenium > > > > > server after run the tests? > > > > > > Thanks, > > > > > > Jian > > > > > > On May 25, 3:10 pm, Jian Fang <[email protected]> wrote: > > > > > > Haroon used Selenium Grid and hope he can give you some suggestions. > > > > > > > Thanks, > > > > > > > Jian > > > > > > > On Tue, May 25, 2010 at 3:06 PM, Jason <[email protected]> wrote: > > > > > > > hey all, > > > > > > > > I've got a periodic hang at the end of my test suite during > > > > > > > SeleniumConnector.disconnectSeleniumServer() -- it's not > > > consistent, > > > > > > > but quite frequent. > > > > > > > > Can you advise on what may cause this, and (if it can't easily be > > > > > > > fixed) a workaround? ie: can I execute this in its own thread and > > > > > > > kill it if it hangs and retry? I'm not sure if this approach will > > > > > > > help at all. If I just end the suite without the disconnect, I > > > > > > > believe my selenium session will stay permanently active, right? > > > > > > > > Here's what's happening on the tellurium (client/ant) side: > > > > > > > > [groovyt] "main" prio=10 tid=0x000000005b3cd800 nid=0x7277 > > > runnable > > > > > > > [0x0000000040208000] > > > > > > > [groovyt] java.lang.Thread.State: RUNNABLE > > > > > > > [groovyt] at java.net.SocketInputStream.socketRead0(Native > > > > > > > Method) > > > > > > > [groovyt] at > > > > > > > java.net.SocketInputStream.read(SocketInputStream.java:129) > > > > > > > [groovyt] at > > > > > > > java.io.BufferedInputStream.fill(BufferedInputStream.java:218) > > > > > > > [groovyt] at > > > > > > > java.io.BufferedInputStream.read1(BufferedInputStream.java:258) > > > > > > > [groovyt] at > > > > > > > java.io.BufferedInputStream.read(BufferedInputStream.java:317) > > > > > > > [groovyt] - locked <0x00002aaab092d108> (a > > > > > > > java.io.BufferedInputStream) > > > > > > > [groovyt] at > > > > > > > sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687) > > > > > > > [groovyt] at > > > > > > > sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632) > > > > > > > [groovyt] at > > > > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.... > > > > > > > 1072) > > > > > > > [groovyt] - locked <0x00002aaab091b798> (a > > > > > > > sun.net.www.protocol.http.HttpURLConnection) > > > > > > > [groovyt] at > > > > java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:373) > > > > > > > [groovyt] at > > > > com.thoughtworks.selenium.HttpCommandProcessor.getResponseCode(HttpCommandProcessor.java: > > > > > > > 144) > > > > > > > [groovyt] at > > > > com.thoughtworks.selenium.HttpCommandProcessor.getCommandResponseAsString(HttpCommandProcessor.java: > > > > > > > 164) > > > > > > > [groovyt] at > > > > com.thoughtworks.selenium.HttpCommandProcessor.executeCommandOnServlet(HttpCommandProcessor.java: > > > > > > > 104) > > > > > > > [groovyt] at > > > > com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java: > > > > > > > 86) > > > > > > > [groovyt] at > > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > > > > > > Method) > > > > > > > [groovyt] at > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: > > > > > > > 39) > > > > > > > [groovyt] at > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > > > > > > > 25) > > > > > > > [groovyt] at java.lang.reflect.Method.invoke(Method.java:597) > > > > > > > [groovyt] at > > > > > > > org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite > > > > $PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java: > > > > > > > 229) > > > > > > > [groovyt] at > > > > org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java: > > > > > > > 52) > > > > > > > [groovyt] at > > > > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java: > > > > > > > 40) > > > > > > > [groovyt] at > > > > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java: > > > > > > > 117) > > > > > > > [groovyt] at > > > > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java: > > > > > > > 129) > > > > > > > [groovyt] at > > > > org.tellurium.connector.CustomSelenium.cleanSelectorCache(CustomSelenium.groovy: > > > > > > > 145) > > > > > > > [groovyt] at org.tellurium.connector.CustomSelenium > > > > > > > $cleanSelectorCache.call(Unknown Source) > > > > > > > [groovyt] at > > > > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java: > > > > > > > 40) > > > > > > > [groovyt] at > > > > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java: > > > > > > > 117) > > > > > > > [groovyt] at > > > > org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java: > > > > > > > 121) > > > > > > > [groovyt] at > > > > org.tellurium.connector.SeleniumConnector.disconnectSeleniumServer(SeleniumConnector.groovy: > > > > > > > 91) > > > > > > > > here's what's going on on the grid -- not sure which of these > > > threads > > > > > > > is communicating with the selenium server... > > > > > > > > "Thread-1" daemon prio=6 tid=0x02f8a400 nid=0xcb8 runnable > > > > > > > [0x030af000] > > > > > > > java.lang.Thread.State: RUNNABLE > > > > > > > at java.io.FileInputStream.readBytes(Native Method) > > > > > > > at java.io.FileInputStream.read(FileInputStream.java:177) > > > > > > > at > > > > org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java:92) > > > > > > > at java.lang.Thread.run(Thread.java:619) > > > > > > > > "Thread-0" daemon prio=6 tid=0x02f84800 nid=0x4fc runnable > > > > > > > [0x0305f000] > > > > > > > java.lang.Thread.State: RUNNABLE > > > > > > > at java.io.FileInputStream.readBytes(Native Method) > > > > > > > at > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "tellurium-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tellurium-users?hl=en.
