Last time one of our application hit a strange issue. It happens from time to time (but not regularly) that some GWT RPC calls are duplicated.
Sample from the server logs:
2017-04-07 17:11:29,548 DEBUG AuthenticationChecker [ 67] - For: SearchServiceImpl.getDocSearchResults.......................................
2017-04-07 17:11:29,548 DEBUG AuthenticationChecker [ 67] - For: SearchServiceImpl.getDocSearchResults.......................................
AuthenticationChecker is an aspect that logs above information before every service method call.
As you can see two calls are done exactly in the same millisecond.
Do you have any idea what could case duplicated server calls in GWT/GXT application?
I would be appreciated for any help.
Related
I am currently trying to fuzz a PDF viewer with the AFL fuzzer (American Fuzzy Lop).
My problem is quite simple, afl-fuzz expect the application to take an input and close after processing it. But, the PDF viewer is intended to open the document and stay open until closed. The result is that afl-fuzz reach the timeout for all initial inputs and decide to stop here.
...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:myPDFsample00.pdf'...
[*] Spinning up the fork server...
[+] All right - fork server is up.
[!] WARNING: Test case results in a timeout (skipping)
[*] Attempting dry run with 'id:000001,orig:myPDFsample01.pdf'...
[!] WARNING: Test case results in a timeout (skipping)
[*] Attempting dry run with 'id:000002,orig:myPDFsample02.pdf'...
[-] PROGRAM ABORT : All test cases time out, giving up!
Location : perform_dry_run(), afl-fuzz.c:2883
I would like to know how to tell AFL to consider that reaching the timeout and get the program terminated is a "normal" behavior for the test case.
In fact, the usual way to do seems to simply instrument the code of the software you are looking at by adding an exit(0) after the parsing.
It seems quite basic, but I works...
The other way could be to change the meaning of a timeout in the AFL software. But, then, it won't detect 'hangs' when your software might enter a never ending loop.
So, the best way really seems to add an exit(0) (or return 0 if you are in main()) inside your target software just after the parsing is done.
I have a strange issue (hope you can help): I am working on a GWT Web Application that has times when more than 4 - 5 GWT RPC calls are made in the same time - as far as time is concerned.
Every once in a while - once every 15 calls maybe? The return Object from one call, gets 'assigned' to another. I have proof of this by using the gwt-log library on the client side.
Here the return object of the HistoryChangesCount call, got assigned to the modelingGetTemplates call also.
Thus resulting in a ClassCastException in the client file that made the call, on the same line as the onSuccess method.
Do you have any tips on how I can avoid this?
PS - I log every response object.toString() on error level. I know it's not best practice. It's just for troubleshooting.
[14:38:01.026] "(-:-) 2014-04-03 14:38:01,025 [ERROR] getHistoryChangesCount - HistoryPreviewFacet - SUCCESS RETURNED: HistoryChangesCount{dateToNumberOfChangesMap={Mon Mar 31 03:00:00 GMT+300 2014=3}, lastUpdatedOn=Mon Mar 31 11:11:02 GMT+300 2014}
"
[14:38:01.163] "(-:-) 2014-04-03 14:38:01,162 [ERROR] modelingGetTemplates - ModelingTemplatesDropdown - SUCCESS RETURNED: HistoryChangesCount{dateToNumberOfChangesMap={Mon Mar 31 03:00:00 GMT+300 2014=3}, lastUpdatedOn=Mon Mar 31 11:11:02 GMT+300 2014}
"
[14:38:01.175] "(-:-) 2014-04-03 14:38:01,174 [ERROR] Browser: null
java.lang.ClassCastException
at Unknown.iCb(StackTraceCreator.java:174)
at Unknown.sd(StackTraceCreator.java:508)
at Unknown.Txn(Throwable.java:46)
at Unknown.kIc(Cast.java:46)
at Unknown.rff(ModelingTemplatesDropdown.java:79)
at Unknown.bXi(AsyncWrapperForRPCManager.java:38)
at Unknown.Loe(RequestCallbackAdapter.java:232)
at Unknown.MWb(Request.java:258)
at Unknown.qXb(RequestBuilder.java:412)
at Unknown.anonymous(XMLHttpRequest.java:351)
at Unknown.eBb(Impl.java:189)
at Unknown.hBb(Impl.java:242)
at Unknown.anonymous(Impl.java:70)
"
Here is how a successful call to modelingGetTemplates looks like:
[14:37:24.933] "(-:-) 2014-04-03 14:37:24,932 [ERROR] modelingGetTemplates - ModelingTemplatesDropdown - SUCCESS RETURNED: [Advanced Business Application, Advanced Business Transaction, TestTemplate]
"
I am using vanilla GWT-RPC. I only have a class that extends AsyncWrapper for logging. I also created myself a client side queue that limits the number of parallel calls to 4, but even so it still happens.
Versions:
GWT: 2.5.1
and I also use Sencha GXT, not sure if relevant.
Here is a video of the issue reproducing - at 0:30 - this time another call get's the object from modelingGetTemplates.
The end result is that my widget is stuck on loading waiting for data forever. And of course angry users :)
Documenting the way I got around this, rather than fixing it :) (because I couldn't find a fix)
I created a client side GWT RPC call queue.
Any RPC call made by the UI was registring the call to the queue, and the queue would manage (during high load, read delay), the actual execution of the calls.
It acted similar to a thread pool. I had a constant of how many parallel calls I can have at one time, and also a minimum time interval between two calls. I believe it was eventually set to 200 milliseconds.
So by doing the above I (almost) never got that issue. The frequency was so low, nobody noticed it anymore.
My guess of the cause below:
I believe the GWT framework has some maps that use a key that depends on the timestamp of the calls, and if two calls happen at the same time, the map could switch the calls, messing up the results to calls mapping.
I have the following architecture at the moment:
Load(Play app with basic interface for load tests) -> Gateway(Spray application with REST interface for incoming messages) -> Processor(akka app that works with MongoDB) -> MongoDB
Everything works fine as long as number of messages I am pushing through is low. However when I try to push 10000 events, that will eventully end up at MongoDB as documents, it stops at random places, for example on 742 message or 982 message and does nothing after.
What would be the best way to debug such situations? On the load side I am just pushing hard into the REST service:
for (i ← 0 until users) workerRouter ! Load(server, i)
and then in the workerRouter
WS.url(server + "/track/message").post(Json.toJson(newUser)).map { response =>
println(response.body)
true
}
On the spray side:
pathPrefix("track") {
path("message") {
post {
entity(as[TrackObj]) { msg =>
processors ! msg
complete("")
}
}
}
}
On the processor side it's just basically an insert into a collection. Any suggestions on where to start from?
Update:
I tried to move the logic of creating messages to the Gatewat, did a cycle of 1 to 10000 and it works just fine. However if spray and play are involed in a pipeline it interrupts and random places. Any suggestions on how to debug in this case?
In a distributed and parallel environment it is next to impossible to create a system that work reliably. Whatever debugging method you use it will only allow you to find a few bugs that will happen during the debug session.
Once our team spent 3 months(!) while tuning an application for a robust 24/7 working. And still there were bugs. Then we applied a method of Model checking (Spin). Within a couple of weeks we implemented a model that allowed us to get a robust application. However, model checking requires a bit different way of thinking and it can be difficult to start.
I moved the load test app to Spray framework and now it works like a charm. So I suppose the problem was somewhere in the way that I used WS API in Play framework:
WS.url(server + "/track/message").post(Json.toJson(newUser)).map { response =>
println(response.body)
true
}
The problem is resovled but not solved, won't work on a solution based on Play.
I'm using EF6 rc1 with Code First strategy, without precompiled views and the problem is:
If I compile and run the exe application it takes like 15 seconds to run the first query (that's okay, since I'm still working on the pre-generated views). But if I use Visual Studio 2013 Preview to Debug the exact same application it takes almost 2 minutes BEFORE running the first query:
Dim Context = New MyEntities()
Dim Query = From I in Context.Itens '' <--- The debug takes 2 minutes in here
Dim Item = Query.FirstOrDefault()
Is there a way to remove this extra time? Am I doing something wrong here?
Ps.: The context itself is not complicated, its just full with 200+ tables.
Edit: Found out that the problem is that during debug time the EF appears to be generating the Views ignoring the pre-generated ones.
Using the source code from EF I discovered that the property:
IQueryProvider IQueryable.Provider
{
get
{
return _provider ?? (_provider = new DbQueryProvider(
GetInternalQueryWithCheck("IQueryable.Provider").InternalContext,
GetInternalQueryWithCheck("IQueryable.Provider").ObjectQueryProvider));
}
}
is where the time is being consumed. But this is strange since it only takes time in debug. Am I missing something here?
Edit: Found more info related to the question:
Using the Process Monitor (by Sysinternals) I found out that there its the 'desenv.exe' process that is consuming tons of time. To be more specific its consuming time with an 'Thread Exit'. It repeats the Thread Exit stack 36 times. I don't know if this info is very useful, but I saved a '.cvs' with the stack, here is his body: [...] (edit: removed the '.cvs' body, I can post it again by the comments if someone really think its going to be useful, but it was confusing and too big.)
Edit: Installed VS2013 Ultimate and Entity Framework 6 RTM. Installed the Entity Framework Power Tools Beta 4 and used it to generate the Views. Nothing changed... If I run the exe it takes 20 seconds, if I 'Start' debugging it takes 120 seconds.
Edit: Created a small project to simulate the error: http://sdrv.ms/16pH9Vm
Just run the project inside the environment and directly through the .exe, click the button and compare the loading time.
This is a known performance issue in Lazy (which EF is using) when the debugger is attached. We are currently working on a fix (the current approach we are looking at is removing the use of Lazy). We hope to ship this fix in a patch release soon. You can track progress of this issue on our CodePlex site - http://entityframework.codeplex.com/workitem/1778.
More details on the coming 6.0.2 patch release that will include a fix are here - http://blogs.msdn.com/b/adonet/archive/2013/10/31/ef6-performance-issues.aspx
I don't know if you have found the solution. But in my case, I had similar issue which wasted me close to a week after trying different suggestions. Finally, I found a solution by changing my web.config to optimizeCompilations="true" and performance improved dramatically from 15-30 seconds to about 2 seconds.
I am looking for a method to detect if the gsoap web service is available.
Unfortunately when the service is offline then the client gsoap calls block
for a long time. Setting the soap.recv_timeout and the soap.send_timeout to
zero do not help.
This is a bit late, but I finally found (what I think is) a better answer by skulking through the source code (why they don't document this, I don't know):
Look for "soap.connect_timeout". When I set this to 3, it times-out after 3 seconds as expected when the web service is unavailable.
The above recv_timeout and send_timeout didn't work for me in the case of "service unavailable".
I'm pretty sure that by setting soap.recv_timeout and soap.send_timeout with 0 means NO TIMEOUT. Try set this variables with 1 (1 means 1 second).
I came here looking for a solution to the same problem and recognized the erroneous part about setting recv_timeout to 0, but I had set it to 20 and still got no timeout, so I followed the second post and used connect_timeout, which did work as I intended.