Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » ClassCastException in JUnit integration tests(ClassCastException with nested remote calls in single JVM)
ClassCastException in JUnit integration tests [message #1698968] Fri, 19 June 2015 08:26 Go to next message
Robert Lechner is currently offline Robert LechnerFriend
Messages: 7
Registered: December 2014
Junior Member
Hello!

We switched our remote services from RMI to ECF and now we get strange errors in JUnit tests.

We are using JUnit for integration tests. That means we start client and server code inside the unit test and run the full business logic there. We also use "real" remote services; that means we call ECF in a way that we get a remote proxy and do a remote call, the same way as if the server would run in a separate JVM. This gives us the possibility to find serialization problems.

It also happens very often that the implementation of a remote service calls another remote service. And now we come to the problem.

Our integration tests (a few thousands) are grouped into about 100 tests suits. Every tests suite is executed in its own JVM, so they don't have any side effects on each other.

In almost every run of the whole package, one ore two suites are failing with the same problem: the call of a remote service fails with an java.lang.ClassCastException. I attached the complete stack trace of such an exception.

It is non-deterministic, which suite or test is failing and which service is called.
Only a small number of tests are failing with this problem (about 1%).

But the problem is always the same: the return type of the method is A, but the return object is of type B. So we get "B cannot be cast to A". The question is: where does the object of type B come from?

Another observation is, that the problem occurs, if one remote service calls another one.
Is it possible that the problem occurs because of the fact that we do remote calls, but caller and callee are in the same JVM?

I wrote special unit tests to reproduce the problem, but was not able to do so.
Do you have an idea where the problem could be located? What is a good place to take a look? I could wrap a dynamic proxy around the ECF proxy to log more information, when the exception is thrown. Because of the high number of tests, I would get a result after a short time.

Any help is appreciated.
Re: ClassCastException in JUnit integration tests [message #1699020 is a reply to message #1698968] Fri, 19 June 2015 14:51 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1030
Registered: July 2009
Senior Member
Robert Lechner wrote on Fri, 19 June 2015 04:26
Hello!

We switched our remote services from RMI to ECF and now we get strange errors in JUnit tests.

We are using JUnit for integration tests. That means we start client and server code inside the unit test and run the full business logic there. We also use "real" remote services; that means we call ECF in a way that we get a remote proxy and do a remote call, the same way as if the server would run in a separate JVM.



Hi Robert.

Could you please describe what you mean by 'call ECF in a way that we get a remote proxy and do a remote call'? Plain JUnit testing of remoting (multi-process) is tricky, especially in OSGi environment as classloading can be subtle. And it does seem from the stack trace that may be related to classloading.

It appears from the stack trace that the root exception is

java.lang.ClassCastException: com.wamas.wms.biz.wh.pla.cache.PlaElement cannot be cast to com.wamas.mfs.core.mfm.lib.orderpool.TransportOrderMirror

This apparently happens inside a proxy as the top of this part of the stack is:

at com.sun.proxy.$Proxy607.getTransportOrder(Unknown Source)

I assume this is an implementation of a remote service calling into another remote service.

It might be better to correspond about this directly if you don't mind. My personal email is slewis at composent.com, if you would send me a direct note I should be able to help diagnose more easily and quickly (and confidentially if you wish).

Quote:


This gives us the possibility to find serialization problems.

It also happens very often that the implementation of a remote service calls another remote service. And now we come to the problem.

Our integration tests (a few thousands) are grouped into about 100 tests suits. Every tests suite is executed in its own JVM, so they don't have any side effects on each other.

In almost every run of the whole package, one ore two suites are failing with the same problem: the call of a remote service fails with an java.lang.ClassCastException. I attached the complete stack trace of such an exception.

It is non-deterministic, which suite or test is failing and which service is called.
Only a small number of tests are failing with this problem (about 1%).

But the problem is always the same: the return type of the method is A, but the return object is of type B. So we get "B cannot be cast to A". The question is: where does the object of type B come from?

Another observation is, that the problem occurs, if one remote service calls another one.
Is it possible that the problem occurs because of the fact that we do remote calls, but caller and callee are in the same JVM?



Yes, I suppose it is possible. One question: Have you tried to run code similar to the test code (one remote service calling another one) in two separate JVM/processes? Do you see similar results?

Quote:

I wrote special unit tests to reproduce the problem, but was not able to do so.
Do you have an idea where the problem could be located?

Not immediately, unfortunately. One thought: do you have more than one version any of your classes present in the test VM? Also: What OSGi framework are you using, and are you using Eclipse's JUnit plugin tests (as opposed to 'normal' JUnit tests?). And what version of Eclipse (if using Eclipse)?

Quote:


What is a good place to take a look? I could wrap a dynamic proxy around the ECF proxy to log more information, when the exception is thrown. Because of the high number of tests, I would get a result after a short time.



That might provide some useful information. Can you debug into this JUnit code? (and look at the state of things when the problem occurs/catch the exception?)

I think to diagnose such a complex use case it would faster to correspond directly. If you don't mind, please send email to slewis at composent.com.
Re: ClassCastException in JUnit integration tests [message #1699149 is a reply to message #1699020] Mon, 22 June 2015 06:54 Go to previous message
Robert Lechner is currently offline Robert LechnerFriend
Messages: 1
Registered: June 2015
Junior Member
Hello Scott, thank you for the quick answer.

Our applications (desktop clients, server processes) are all based on Eclipse RCP 4.4.2
Of course we are running our tests as plugin tests, not standard Java tests.
Everything worked fine, until we switched from RMI to ECF 3.9.2

I don't think that we have classloading problems or any other general problem.
We run 6000 tests and about 5 are failing, but it is non-deterministic which are failing. If the setup would be wrong, almost all tests would fail.

Scott, I'll send you more detailed information per email.
Previous Topic:ECF 3.9.2 released
Next Topic:Securing OSGi Remote Services implemented using ECF
Goto Forum:
  


Current Time: Fri Sep 21 14:14:01 GMT 2018

Powered by FUDForum. Page generated in 0.05301 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top