4

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 :)

Alex
  • 311
  • 2
  • 17
  • 1
    Can you include the two method signatures, as well as the code where you're logging the response objects? – tangent Feb 10 '15 at 20:57
  • Can't you make a single call (or fewer calls) to return the objects you need? – Gilberto Torrezan May 31 '15 at 01:41
  • I guess that could be part of a permanent solution... However I'm not working on this project anymore. I did find another (less obvious) way of solving it 99% of the time. I'll write an answer on how I did it. – Alex Jun 01 '15 at 10:42

1 Answers1

0

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.

Alex
  • 311
  • 2
  • 17