18 January 2026:


This forum is now archived and is in read-only mode. Please continue discussions on our improved new Sahi Pro Community forum.



Sahi Pro is an enterprise grade test automation platform which can automate web, mobile, API, windows and java based applications and SAP.

Waiting for socket problem

pankaj.nithpankaj.nith Members
edited November -1 in Sahi - Open Source
Hi,

I am facing a peculiar problem on particular pages only. While running my sahi script, the script gets stuck on some particular pages as the page does not load completely and controller keeps on waiting for the page to load.
If I check the command window the message appearing is "Waiting for socket". Any suggestions please. I need a solution asap.

Thanks and Regards,
Pankaj.

Comments

  • And this is with the most recent version of Sahi?

    Have you tried rolling back to the pre-June 25th build?
  • Nope..:(
    This is an older version of Sahi (Build: 2007-10-21) with some tweakings done as per our requirements.

    Regards,
    Pankaj.
  • pankaj.nithpankaj.nith Members
    edited July 2008
    Any thoughts on this... :(
  • Holiday weekend here so I was out of town...

    I'm not positive but my guess is that Sahi waits for the page "Done" event to fire before continuing so I'm thinking you might be in trouble.

    Any particular reason the page does not finish loading? That sounds like a bug to me.
  • pankaj.nithpankaj.nith Members
    edited July 2008
    ya...u r right. It happens on particular pages with FCKEditor in them. But i wonder whether its a bug on the application end or in sahi. :(
    Couldnt see any light at the end of the tunnel till now.
    Any suggestions or workaround?

    Thanks and regards,
    Pankaj.
  • Hi Pal,

    the application you are talking about already has lakhs of end users, and the functionality when it is run manually is not broken.

    2nd Workaround: Enable all the web services (also ensure that http proxy service is running on the machine where you run Sahi tests. Hopefully, most of your problems should get sorted out (if not all). For the rest, its going to be a tedious task.

    1. Diagnozing the bug (which is there somewhere in Sahi handling)

    2. Giving a workaround by any other tool, or ask sahi guys /maybe yourself going deep. But here is what you need to do:

    1. Use kgdb/ any good stack trace tools for java which capture java threads. (There is no workaround here :( you really need to figure out the thread which is causing the deadlock/magic escape. The reasons could be manifold.

    So the Waiting for Socket error message can be nailed down by identifying the stack trace associated with the corresponding socket, and pointing out to the right thread which most likely is going to be the magician. The socket would be having multiple threads, and one of them would be giving the problem (can be due to variables/ID's mismatch resulting in making the respective thread to vanish/perish. So even if 1 thread is causing it, the socket still waits :(

    Abhinav
  • narayannarayan Administrators
    Pankaj,

    Seems like there are NO sockets available in the pool to service the requests. Try setting http.keep_alive=false in sahi.properties and restarting Sahi.
    Let me know if this solves the issue.

    Or if you guys are able to build Sahi then open RemoteRequestProcessor and increase the size of the socketpool.

    private static SocketPool socketPool = new SocketPool(100); // change 100 to some higher number.
  • Hi,

    I have tried setting 'http.keep_alive = false' but it didn't resolve the problem.
    Have also tried setting the TCP/IP parameters in registry to allow maximum number of sockets and minimum wait time to relinquish a socket. That also didnt help. I also downloaded the Sahi sourcecode but dont have much idea how to build from that. Any guidance to do so will be helpful.

    Thanks and Regards,
    Pankaj.
  • Dear Narayan, this is not the problem. Actually its w.r.t. memory leakage issue that one of the threads is causing which leads the thread to a deadlock and consequently the socket keeps waiting. Here is the proof of the stack trace dump. Socket has various threads, and even if 1 of them goes into deadlock, the socket will still keep waiting. I have seen this and here is the dump (just the pointer where the exception has happened).

    "Low Memory Detector" daemon prio=6 tid=0x00a71310 nid=0xcc0 runnable [0x00000000..0x00000000]
    "CompilerThread0" daemon prio=10 tid=0x00a6fdb0 nid=0x454 waiting on condition [0x00000000..0x02bcf948]
    "Signal Dispatcher" daemon prio=10 tid=0x00a6f0e0 nid=0xaec runnable [0x00000000..0x00000000]

    The problem is Sahi gets into similar issues only if the application size is huge, has multiple complexities, or you are using for stress/perf/soak testing. That also could be one of the reasons this particular issue never ever came in the current forum.

    The stack trace does help to trace the exception, but what about resolution. Any ideas ?
  • The stack trace dump size is significant, so did not want to paste it here as would become irritating to various pals around. Any alternative mail id etc, where I could possibly send the same.
  • Hi Pal, did you actually understand the problem ( I mean nailing down to the exact thread that's getting deadlocked), ending up creating socket problems.

    And did you get a solution, in case you do. Please do share.
  • narayannarayan Administrators
    Looking at it ...
  • BastBast Members
    hello,
    i'm apologize for my english, i'm french ...


    i am using latest version.
    i have a problem with sahi.
    i can't test a part of my web application.

    in this part,sahi must click to icon.

    sahi begin with socket 13400 and
    the proxy blocks when socket is 13500 with a waiting for socket.

    between every :"### Creating New Socket : 134XX"

    i can see this message:

    java.net.ConnectException: Connection refused: connect
    at java.net.PlainSocketImpl.socketConnect(Native Method)
    at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
    at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
    at java.net.Socket.connect(Socket.java:452)
    at java.net.Socket.connect(Socket.java:402)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:78)
    at net.sf.sahi.RemoteRequestProcessor.getReusableSocket(RemoteRequestPro
    cessor.java:133)
    at net.sf.sahi.RemoteRequestProcessor.getNormalSocket(RemoteRequestProce
    ssor.java:128)
    at net.sf.sahi.RemoteRequestProcessor.getSocketToHost(RemoteRequestProce
    ssor.java:112)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor
    .java:69)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor
    .java:62)
    at net.sf.sahi.ProxyProcessor.processAsProxy(ProxyProcessor.java:110)
    at net.sf.sahi.ProxyProcessor.run(ProxyProcessor.java:76)
    at java.lang.Thread.run(Thread.java:534)

    I put http.keep_alive = false but nothing


    Any suggestions would be very helpful

    Thank you

    Bast
  • Hi,

    You seem to have the same problem as i am having. The socket pool is running out of sockets after using all the available sockets (100). Try breaking the script into parts and run the parts through some batch file (suite). I am not sure this will resolve your poblem or not but do give it a try.

    Regards,
    Pankaj.
  • There is a fundamental issue here, 1: Each socket consists of so many threads, and even if 1 of many (maybe 50) goes not return, it will keep on waiting and nothing will happen. Generally it happens coz one of the thread dies/deadlocks (which is certainly because of memory handling).
    So what Pankaj has mentioned makes sense because breaking the script to sub modules will ensure that memory does not become an issue.
    I can share the stack trace in case it helps
  • Hi Narayan,

    Any updates or any workaround for this problem?
    :(

    Pankaj.
  • I do not know whether my mail helped to clarify or not: Here is the code that demonstrates it: just 1 thread which is going into deadlock leads the socket to wait endlessly (VM issue- As the stack trace claims).
    "StackTrace Remote Thread" prio=6 tid=0x02c5ae88 nid=0xa80 runnable [0x00000000..0x0346fa44]

    "Thread-32193" prio=6 tid=0x00aba368 nid=0x8d0 runnable [0x0342f000..0x0342f9e8]
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)
    at net.sf.sahi.StreamHandler.setRawHeaders(StreamHandler.java:94)
    at net.sf.sahi.StreamHandler.populateHeaders(StreamHandler.java:43)
    at net.sf.sahi.request.HttpRequest.<init>(HttpRequest.java:57)
    at net.sf.sahi.ProxyProcessor.getRequestFromBrowser(ProxyProcessor.java:150)
    at net.sf.sahi.ProxyProcessor.run(ProxyProcessor.java:57)
    at java.lang.Thread.run(Unknown Source)

    "Thread-31869" prio=6 tid=0x00a763a0 nid=0xdd8 in Object.wait() [0x02f2f000..0x02f2fbe8]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x22f72260> (a java.util.LinkedList)
    at java.lang.Object.wait(Unknown Source)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:58)
    - locked <0x22f72260> (a java.util.LinkedList)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:71)
    at net.sf.sahi.RemoteRequestProcessor.getReusableSocket(RemoteRequestProcessor.java:133)
    at net.sf.sahi.RemoteRequestProcessor.getNormalSocket(RemoteRequestProcessor.java:128)
    at net.sf.sahi.RemoteRequestProcessor.getSocketToHost(RemoteRequestProcessor.java:112)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:69)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:62)
    at net.sf.sahi.ProxyProcessor.processAsProxy(ProxyProcessor.java:110)
    at net.sf.sahi.ProxyProcessor.run(ProxyProcessor.java:76)
    at java.lang.Thread.run(Unknown Source)

    "Thread-31868" prio=6 tid=0x02c54da8 nid=0xeb4 in Object.wait() [0x033af000..0x033afc68]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x22f72260> (a java.util.LinkedList)
    at java.lang.Object.wait(Unknown Source)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:58)
    - locked <0x22f72260> (a java.util.LinkedList)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:71)
    at net.sf.sahi.RemoteRequestProcessor.getReusableSocket(RemoteRequestProcessor.java:133)
    at net.sf.sahi.RemoteRequestProcessor.getNormalSocket(RemoteRequestProcessor.java:128)
    at net.sf.sahi.RemoteRequestProcessor.getSocketToHost(RemoteRequestProcessor.java:112)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:69)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:62)
    at net.sf.sahi.ProxyProcessor.processAsProxy(ProxyProcessor.java:110)
    at net.sf.sahi.ProxyProcessor.run(ProxyProcessor.java:76)
    at java.lang.Thread.run(Unknown Source)

    "Thread-30682" prio=6 tid=0x00a7f9d8 nid=0x8d8 in Object.wait() [0x02f6f000..0x02f6fd68]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x22f72260> (a java.util.LinkedList)
    at java.lang.Object.wait(Unknown Source)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:58)
    - locked <0x22f72260> (a java.util.LinkedList)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:71)
    at net.sf.sahi.RemoteRequestProcessor.getReusableSocket(RemoteRequestProcessor.java:133)
    at net.sf.sahi.RemoteRequestProcessor.getNormalSocket(RemoteRequestProcessor.java:128)
    at net.sf.sahi.RemoteRequestProcessor.getSocketToHost(RemoteRequestProcessor.java:112)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:69)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:62)
    at net.sf.sahi.ProxyProcessor.processAsProxy(ProxyProcessor.java:110)
    at net.sf.sahi.ProxyProcessor.run(ProxyProcessor.java:76)
    at java.lang.Thread.run(Unknown Source)

    "Thread-30389" prio=6 tid=0x00aafdb0 nid=0x618 in Object.wait() [0x02e8f000..0x02e8fbe8]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x22f72260> (a java.util.LinkedList)
    at java.lang.Object.wait(Unknown Source)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:58)
    - locked <0x22f72260> (a java.util.LinkedList)
    at net.sf.sahi.util.SocketPool.get(SocketPool.java:71)
    at net.sf.sahi.RemoteRequestProcessor.getReusableSocket(RemoteRequestProcessor.java:133)
    at net.sf.sahi.RemoteRequestProcessor.getNormalSocket(RemoteRequestProcessor.java:128)
    at net.sf.sahi.RemoteRequestProcessor.getSocketToHost(RemoteRequestProcessor.java:112)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:69)
    at net.sf.sahi.RemoteRequestProcessor.processHttp(RemoteRequestProcessor.java:62)
    at net.sf.sahi.ProxyProcessor.processAsProxy(ProxyProcessor.java:110)
    at net.sf.sahi.ProxyProcessor.run(ProxyProcessor.java:76)
    at java.lang.Thread.run(Unknown Source)

    "Low Memory Detector" daemon prio=6 tid=0x00a71310 nid=0xcc0 runnable [0x00000000..0x00000000]

    "CompilerThread0" daemon prio=10 tid=0x00a6fdb0 nid=0x454 waiting on condition [0x00000000..0x02bcf948]

    "Signal Dispatcher" daemon prio=10 tid=0x00a6f0e0 nid=0xaec runnable [0x00000000..0x00000000]

    "Finalizer" daemon prio=8 tid=0x00a6a1e8 nid=0xcc4 in Object.wait() [0x02b4f000..0x02b4fbe8]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x22f62a90> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(Unknown Source)
    - locked <0x22f62a90> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(Unknown Source)
    at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

    "Reference Handler" daemon prio=10 tid=0x0003fcf0 nid=0xafc in Object.wait() [0x02b0f000..0x02b0fce8]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x22f62b10> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Unknown Source)
    at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
    - locked <0x22f62b10> (a java.lang.ref.Reference$Lock)

    "main" prio=6 tid=0x00035f18 nid=0xb74 runnable [0x0007f000..0x0007fc3c]
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.PlainSocketImpl.accept(Unknown Source)
    - locked <0x22f717f0> (a java.net.SocksSocketImpl)
    at java.net.ServerSocket.implAccept(Unknown Source)
    at java.net.ServerSocket.accept(Unknown Source)
    at net.sf.sahi.Proxy.startProxy(Proxy.java:59)
    at net.sf.sahi.Proxy.main(Proxy.java:40)

    "VM Thread" prio=10 tid=0x00a47328 nid=0x514 runnable

    "VM Periodic Task Thread" prio=10 tid=0x00a72568 nid=0xb7c waiting on condition
  • Let me know in case you face any further problems. Just maintain a lower code size, and it should take care of the rest.
  • Hi Narayan,

    Any updates on this issue?
    Or please suggest if there is any workaround for this. I have to manually press escape button to stop the page from loading so that the script can move further. :(

    Regards,
    Pankaj.
  • adminadmin Administrators
    Could somebody verify this is fixed in the new build (Sahi V2 20080831) please?

    Download: https://sourceforge.net/project/showfiles.php?group_id=151639&package_id=289756&release_id=623244
  • Definitely!
    Will revert back soon as soon as I complete testing it.

    Thanks aton!
Sign In or Register to comment.