Using Gatling for testing Vaadin

Hello, I hope you’ll forgive me for being a beginner here but I have been searching all day for an answer to this question.

I am trying to use Gatling to load test our web application built using Vaadin.

I can open a web socket connect, push the login message and get the required response, but if I then send another push message the response is not as expected.

I am doing as the tutorial suggests and copying and pasting the messages as they appear in Chrome Developer Tools.

This is my request to move to the search URL, this is generated in Chrome by clicking on a “Searches” link (is the clicking step what I am missing?)

.sendText(“”“182|{“csrfToken”:”${seckey}“, “rpc”:[[”${location}“,“”,“notifyUriChanged”,[“search”]
]], “syncId”:3}”“”)

My response is then

273|for(;;);[{“syncId”: 3, “changes” :[[“change”,{“pid”:“0”},[“0”,{“id”:“0”,“location”:“http://v217s08r2643:8080/getit/#!-”}]
]], “state”:{}, “types”:{“1”:“6”,“0”:“0”}….

But I am expecting

25891|for(;;);[{“syncId”: 3, “changes” : [[“change”,{“pid”:“0”},[“0”,{“id”:“0”,“location”:“http://v217s08r2643:8080/getit/#!-/search”}]

I hope you can help because it’s driving me crazy, and I’m sure it’s a simnple thing I am overlooking.



Hard to say what happens without seeing the full responses, but is your application doing some sort page(/ui) change on that action? At least you seem to be receiving “location” messages from the server. I think this should somehow be handled in you gatling scipts. Probably closing the old websocket communicaiton, getting the new host page and opening new communication like with your login page.


Thanks for your help, as this is all new to me, and I’d never encountered a web socket (that I was aware of) until yesterday I’m a little lost.

I obtain my CSRF and atmosphere key, then I open a socket and push my login message.


523|{“csrfToken”:“${seckey}”, “rpc”:[[“0”,“com.vaadin.shared.ui.ui.UIServerRpc”,“resize”,[“968”,“1280”,“1280”,“968”]
]],[“12”,“com.vaadin.shared.ui.button.ButtonServerRpc”,“click”,[{“metaKey”:false, “altKey”:false, “ctrlKey”:false, “relativeX”:“29”, “relativeY”:“27”, “clientY”:“476”, “clientX”:“796”, “shiftKey”:false, “button”:“LEFT”, “type”:“1”}]
]], “syncId”:1}

The response that I receive is as expected, which shows that the socket is open and I can communicate through it successfully.

4452|for(;;);[{“syncId”: 2, “changes” : [[“change”,{“pid”:“0”},[“0”,{“id”:“0”,“location”:“http://v217s08r2643:8080/getit/#!-”,“v”:{“action”:“”}},[“actions”,{}]
]], “state”:{“22”:{“id”:“org_jamie_web_frontend_navigation_containers_BreadcrumbsAndContentContainer”,“height”:“100.0%”,“width”:“100.0%”,“styles”:[“full-screen-component”,“breadcrumbs-and-content”]
,“childData”:{“31”:{“expandRatio”:1,“alignmentBitmask”:5},“23”:{“expandRatio”:0,“alignmentBitmask”:5}}},“23”:{“templateContents”:“<div location="up-arrow"></div><div location="breadcrumbs"></div><div location="user"></div>”,“childLocations”:{“25”:“breadcrumbs”,“27”:“user”},“width”:“100.0%”,“styles”:[“top-bar”,“overlying-circle”]
},“10”:{“text”:“jamie”},“30”:{“resources”:{“icon”:{“uRL”:“fonticon://FontAwesome/f08b”}},“description”:“Sign Out”,“styles”:[“link”,“small”]
,“childData”:{“32”:{“expandRatio”:0,“alignmentBitmask”:5}}}}, “types”:{“22”:“27”,“23”:“24”,“33”:“25”,“25”:“26”,“26”:“3”,“27”:“28”,“11”:“2”,“28”:“3”,“29”:“3”,“2”:“6”,“10”:“1”,“1”:“7”,“0”:“0”,“30”:“3”,“32”:“29”,“5”:“7”,“31”:“17”}, “hierarchy”:{“22”:[“23”,“31”]
}, “rpc” : [[“2”,“com.vaadin.shared.extension.javascriptmanager.ExecuteJavaScriptRpc”,“executeJavaScript”,[“notvitic.navigation.ViewsNavigator.leafToCircle(‘org_jamie_web_frontend_navigation_containers_BreadcrumbsAndContentContainer’);”]
,“label”:“Searches”,“uri”:“search”},{“icon”:“maintain”,“children”:,“label”:“Maintain”,“uri”:“maintain”},{“icon”:“admin”,“children”:,“label”:“Admin”,“uri”:“admin”},{“icon”:“dataentry”,“children”:,“label”:“Data Entry”,“uri”:“dataentry”}],“label”:null,“uri”:“-”}]]], “meta” : {}, “resources” : {}, “typeMappings” : { “” : 29 , “org.jamie.web.frontend.navigation.breadcrumbs.Breadcrumbs” : 26 , “” : 25 , “com.vaadin.ui.AbsoluteLayout” : 30 , “org.jamie.web.frontend.views.common.AttachableCssLayout” : 31 , “org.jamie.web.frontend.navigation.containers.BreadcrumbsAndContentContainer” : 27 , “com.vaadin.ui.AbstractJavaScriptComponent” : 32 , “” : 28 , “com.vaadin.ui.CustomLayout” : 24 }, “typeInheritanceMap” : { “29” : 30 , “26” : 31 , “25” : 32 , “16” : 19 , “30” : 11 , “31” : 7 , “17” : 21 , “6” : 23 , “18” : 19 , “2” : 15 , “27” : 17 , “19” : 13 , “22” : 10 , “10” : 18 , “11” : 20 , “32” : 19 , “7” : 11 , “28” : 7 , “15” : 16 , “24” : 11 , “0” : 22 , “3” : 19 , “20” : 19 , “1” : 15 , “21” : 11 , “23” : 13 }, “scriptDependencies”: [“published:///vCircleNavigation.js”]
, “timings”:[7, 0]

There then appears to be a further message sent which I am replicating

353|{“csrfToken”:“ca54d523-f529-4a31-9ad0-18487247ac2e”, “rpc”:[[“2”,“com.vaadin.ui.JavaScript$JavaScriptCallbackRpc”,“call”,[“notvitic.navigation.ViewsNavigator.containersSwapped”,[“org_jamie_web_frontend_navigation_containers_FullScreenContainer”,“org_jamie_web_frontend_navigation_containers_BreadcrumbsAndContentContainer”]
]]], “syncId”:2}

and receiving the correct response for

272|for(;;);[{“syncId”: 3, “changes” : [[“change”,{“pid”:“0”},[“0”,{“id”:“0”,“location”:“http://v217s08r2643:8080/getit/#!-”}]
]], “state”:{}, “types”:{“1”:“7”,“0”:“0”}, “hierarchy”:{“1”:[“22”]
}, “rpc” : , “meta” : {}, “resources” : {}, “timings”:[151, 0]

At this point, on the application I would click on the searches link, which would take me to “http://v217s08r2643:8080/getit/#!-/search”

The request I am using is the same as recorded in Chrome

182|{“csrfToken”:“ca54d523-f529-4a31-9ad0-18487247ac2e”, “rpc”:[[“33”,“”,“notifyUriChanged”,[“search”]
]], “syncId”:3}

However the response is the same as the previous 272 character response above, so I am obviously missing some method of changing to the new URL. I can’t see anything that I am missing in the Chrome log though.

I have attached my Gatling script and the Chrome log for the above navigation. I really think that if I can understand this step then I should be ok (don’t hold me to that).

Thanks for your help

17243.txt (3.76 KB)
17244.txt (59.9 KB)

Okay I’ve been looking at the logs and how they differ between a normal browser connection and one using Gatling and it seems that my request

182|{“csrfToken”:“ca54d523-f529-4a31-9ad0-18487247ac2e”, “rpc”:[[“33”,“”,“notifyUriChanged”,[“search”]
]], “syncId”:3}

Is being received and processed (the response is recorded in the log file) but that my client is not receiving the response for some reason.

The only difference between the logs is that this appears

[Wed Nov 2014 16:14:00.414]
DEBUG (org.apache.http.impl.conn.DefaultClientConnection:169) - Connection<-> closed
[Wed Nov 2014 16:14:00.414]
DEBUG (org.apache.http.impl.conn.DefaultClientConnection:169) - Connection<-> closed

In the log of the Gatling connection but not in the browser connection. This appears immediately after my response is produced.

So the question now is, how do I prevent this connection from closing?

Turns out that’s not the issue

It seems to be the # characters that are appearing on all of the Vaadin urls. Gatling doesn’t seem to be able to handle these easily :frowning:


The fragment/anchor part of the url, the part that starts with #, is actually never communicated to the server by default. Vaadin, like many other modern web libraries, use that though to implement “back button support” for “ajax” apps. If you need to simulate a change from e.g.!foo to!bar, you can on both “page entries” just load Vaadins server side gets the full url with the fragment part with the XHR/websocket communication with the subsequent request.

I hope this helps you to get forward!


Thanks for that, I wasn’t lying when I said this was all new to me! :slight_smile:

I’m back to thinking that the issue lies with the connection being unexpectedly closed. I’ve enabled full logging on Gatling and the log from when I send my message is shown below. I’m not sure if this issue is on the Vaadin side or the Gatling side though (I would guess Vaadin since it’s saying that the server closed the connection)

13:33:41.186 [DEBUG]
i.g.h.a.w.WsActor - Sending message check on WebSocket ‘gatling.http.webSocket’: TextMessage(182|{“csrfToken”:“349c1459
-8fb2-49e6-b4d5-7ba893b1d5ab”, “rpc”:[[“33”,“”,“notifyUriChanged”,[“search”]
]], “syncId”:3})
13:33:41.187 [DEBUG]
o.j.n.h.c.h.w.WebSocket08FrameEncoder - Encoding WebSocket Frame opCode=1 length=186
13:33:41.191 [DEBUG]
c.n.h.c.p.n.h.Processor - Channel Closed: [id: 0xb9c51eea, / :> v217s08r2643/]
attribute INSTANCE
13:33:41.192 [INFO ]
i.g.c.c.Controller - End user #3298137887111428876-0
13:33:41.218 [DEBUG]
o.j.n.h.c.h.w.WebSocket08FrameDecoder - Decoding WebSocket Frame opCode=1
13:33:41.239 [DEBUG]
c.n.h.c.p.n.h.Processor - Channel Closed: [id: 0x6ea03df5, / :> v217s08r2643/]
attribute NettyResponseFuture{currentRetry=0,
content=NettyWebSocket{channel=[id: 0x6ea03df5, / :> v217s08r2643/]
Simulation finished
13:33:41.347 [TRACE]
c.n.h.c.p.n.h.WebSocketProtocol - onClose {}
13:33:41.351 [TRACE]
c.n.h.c.p.n.h.WebSocketProtocol - Connection was closed abnormally (that is, with no close frame being sent).
13:33:41.353 [DEBUG]
c.n.h.c.p.n.c.ChannelManager - Closing Channel [id: 0x6ea03df5, / :> v217s08r2643/]

13:33:41.355 [DEBUG]
i.g.h.a.w.WsActor - Websocket ‘gatling.http.webSocket’ closed by the server
13:33:41.365 [DEBUG]
c.n.h.c.p.n.h.Processor - Unexpected I/O exception on channel [id: 0x6ea03df5, / :> v217s08r2643/192.
org.jboss.netty.handler.codec.frame.CorruptedFrameException: Max frame length of 10240 has been exceeded.
at org.jboss.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.protocolViolation( ~[netty
at org.jboss.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.decode( ~[netty-3.9.4.Fina
at org.jboss.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.decode( ~[netty-3.9.4.Final
at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode( ~[netty-3.9.4.Final.jar:na]

    at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived( ~[netty-3.9.4.Final.jar:na]

    at ~[netty-3.9.4.Final.jar

at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at [netty-3.9.4.Final.jar:na]

    at org.jboss.netty.util.internal.DeadLockProofWorker$ [netty-3.9.4.Final.jar:na]

    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.7.0_67]

    at java.util.concurrent.ThreadPoolExecutor$ Source) [na:1.7.0_67]

    at Source) [na:1.7.0_67]

13:33:41.531 [DEBUG]
c.n.h.c.p.n.c.ChannelManager - Closing Channel [id: 0x6ea03df5, / :> v217s08r2643/]

Thank you for your help Matti, talking to you and Stéphane over on the Gatling forums has led me to work out what the issue was myself (it was nothing to do with Vaadin either). Had to change the maximum frame size allowed by the websocket frame decoder. Sounds simple but these things always are after you work them out!