Do you have attributes on your Servlet or other Singleton or single instance Java code ?
On 11 févr. 2011, at 15:11, nrg-b wrote: > > Hello! > > I am using qx.io.remote.Rpc to call some remote Java objects via the > RpcServlet running on TomCat. The Java objects are just boiler-plate code to > proxy the call to our back-end app-server. > > The RPC handler call is the same design as the one in the api example, > except I use a generic rpc handler to invoke a distinct function object > which does all the real handling. This lets me associate different handlers > for each remote service. > > Its working well on an individual basis. But when I have two successive > calls to qx.io.remote.Rpc.callAsync() there appears to be a weird > multiplexing problem. > > > So for example, I have two services A and B. The structure of the returned > data from each is quite different ie easy to tell apart from debug output. > > If I invoke ServiceA then rpc.callAsync() returns an id of (say)10. When my > serviceA handler is invoked the id is also 10 and the data is as expected eg > JSONDataSetA. > > Likewise, if I invoke ServiceB then callAync() might return an id of > (say)11. When my serviceB handler is invoked the id is also 11 and the data > is as expected for service B eg JSONDataSetB. > > But if I invoke both services in quick succession one immediately after the > other, then the expected datasets seem to get swapped!!! > > So to prolong the contrived example above :- > - ServiceA handler gets called with JSONDataSetB, and > - ServiceB handler gets called with JSONDataSetA > > As soon as I introduce a slight delay eg (several calls to console.log()) > between each rpc.callAsync() then the problem goes away. If I call each > service in isolation then all works as expected. > > I am wondering if there is a race situation in the qx.io.remote.Rpc code or > maybe the RpcServlet. I don't think its our app-server as its a real-time > server which already handles multiple-async calls via realtime GUIs. > > Would really appreciate some thoughts/ideas on how to proceed. > > -- > View this message in context: > http://qooxdoo.678.n2.nabble.com/rpc-oddness-tp6015845p6015845.html > Sent from the qooxdoo mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
