Bugzilla – Full Text Bug Listing
| Summary: | [remoteservices][xmpp] containerID field in remote service registry is null | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Scott Lewis <slewis> | ||||||
| Component: | ecf.providers | Assignee: | Scott Lewis <slewis> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | bugs.eclipse.org, reiswich | ||||||
| Version: | 3.4.0 | Flags: | bugs.eclipse.org:
iplog+
|
||||||
| Target Milestone: | 3.4.0 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Hi Scott,
I hunted down the problem following the call hierarchy caused by:
adapter = (IRemoteServiceContainerAdapter) container.getAdapter(IRemoteServiceContainerAdapter.class);
This method calls in ClientSOContainer getConnectedID() which returns null.
According to your advice the adapter is now retrieved in my code before a connection is established.
public SessionServiceImpl() {
try {
container = ContainerFactory.getDefault().createContainer(
ECFConstants.XMPP);
adapter = (IRemoteServiceContainerAdapter) container
.getAdapter(IRemoteServiceContainerAdapter.class);
assert adapter != null : "parameter adapter != null";
registerRosterListener();
} catch (ContainerCreateException e) {
e.printStackTrace();
}
}
public void connect(String userName, String password, String server)
throws URISyntaxException, ECFException {
this.userName = userName;
xmppid = new XMPPID(container.getConnectNamespace(), userName + "@"
+ server);
xmppid.setResourceName("" + System.currentTimeMillis());
IConnectContext connectContext = ConnectContextFactory
.createUsernamePasswordConnectContext(userName, password);
container.connect(xmppid, connectContext);
}
Eugen
Hi Eugen, Thanks for the info. I've been looking at this, and working on what I think will be a permanent fix for the xmpp container's limitations WRT remote services. The main issue, FYI, is that the xmpp providers inability to send remote service registry updates to all members of a 'group' (as there is no group for xmpp clients), requires an additional mechanism be added to the remote service registry. Otherwise, races are possible for populating the registry vs. accessing the registry (for xmpp). I'm in the middle of such an addition/fix (i.e. have already committed a number of fixes and preparation for the permanent fix to master if you are interested in tracking), and expect to have it completed for ECF 3.4. Any additional xmpp test code that you could/would contribute for the xmpp automated tests would be helpful. (In reply to comment #2) > Hi Eugen, > > Thanks for the info. I've been looking at this, and working on what I think > will be a permanent fix for the xmpp container's limitations WRT remote > services. The main issue, FYI, is that the xmpp providers inability to send > remote service registry updates to all members of a 'group' (as there is no > group for xmpp clients), requires an additional mechanism be added to the > remote service registry. Otherwise, races are possible for populating the > registry vs. accessing the registry (for xmpp). Scott, I guess this is a practicable solution. An other way to solve this problem could be in storing remote services at first in a local OSGi registry without updating all members. Only when a member requires a remote service we could do the lookup dynamically. We should have all the necessary information for doing this if XMPPID and ContainerID are the same. This is comparable to the Observer-Pattern in OSGi. One can listen for all observers (=OSGi services), store them temporally in a list and iterate over that list in case of an event and inform observers. The other way is not to store all observers but rather retrieving them dynamically in case of an event from the service registry. This will avoid updating the local observer list every time observers appear or disappear. What do you think? Eugen (In reply to comment #3) <stuff deleted> > > Scott, I guess this is a practicable solution. An other way to solve this > problem could be in storing remote services at first in a local OSGi registry > without updating all members. Only when a member requires a remote service we > could do the lookup dynamically. We should have all the necessary information > for doing this if XMPPID and ContainerID are the same. > This is comparable to the Observer-Pattern in OSGi. One can listen for all > observers (=OSGi services), store them temporally in a list and iterate over > that list in case of an event and inform observers. The other way is not to > store all observers but rather retrieving them dynamically in case of an event > from the service registry. This will avoid updating the local observer list > every time observers appear or disappear. > > What do you think? What I'm working on is something similar to this...essentially having both mechanisms: i.e. 'eager' sharing of remote service registrations...for providers that support that...and 'lazy' retrieval of remote service registrations for providers that do not support the first mechanism (e.g. xmpp). (In reply to comment #4) > What I'm working on is something similar to this...essentially having both > mechanisms: i.e. 'eager' sharing of remote service registrations...for > providers that support that...and 'lazy' retrieval of remote service > registrations for providers that do not support the first mechanism (e.g. > xmpp). So how does this fix affect the behavior of other existing providers? (In reply to comment #5) > (In reply to comment #4) > > > What I'm working on is something similar to this...essentially having both > > mechanisms: i.e. 'eager' sharing of remote service registrations...for > > providers that support that...and 'lazy' retrieval of remote service > > registrations for providers that do not support the first mechanism (e.g. > > xmpp). > > So how does this fix affect the behavior of other existing providers? It shouldn't affect them at all. The existing providers will simply continue to use the existing 'eager' approach. (In reply to comment #6) > It shouldn't affect them at all. The existing providers will simply continue > to use the existing 'eager' approach. What about consumers that exchange e.g. r-OSGi with the XMPP provider? Do they need to adopt their implementation? (In reply to comment #2) > Any additional xmpp test code that you could/would contribute for the xmpp > automated tests would be helpful. Hi Scott, I would really like to contribute tests regarding XMPP. But as I am not an ECF committer I wonder what's the best way to do this? Eugen (In reply to comment #8) > I would really like to contribute tests regarding XMPP. But as I am not an ECF > committer I wonder what's the best way to do this? You should be able to just run the .launch configs that are part of the test projects (might need some Mac-love though) directly from your workspace. The test bundles are part of the official git repo [0]. When you add new tests, they will be automatically picked up by the build/test machine once released to the repo. Markus [0] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/ (In reply to comment #7) > (In reply to comment #6) > > > It shouldn't affect them at all. The existing providers will simply continue > > to use the existing 'eager' approach. > > What about consumers that exchange e.g. r-OSGi with the XMPP provider? Do they > need to adopt their implementation? If they are using ECF remote services API directly...they *will* have to adjust their code to use one of the methods that includes the ID[] idFilter...as the idFilter now will be used to decide which remote containers to request updates from...if they haven't heard from remotes eagerly. If they are using OSGi remote services with discovery, I expect the answer will be 'no'. I'm actively working on addressing this bug so assigning to myself. I've released to master a fix for this bug, as well as dealing with the underlying issue caused by the xmpp container's lacking group messaging support.
The RegistrySharedObject now supports both 'eager' and 'lazy' remote services lookup...meaning that all providers that use the RegistrySharedObject can benefit from this new approach.
In terms of the remote services API in order to find remote services at a given remote ID, the methods to use are those that have the ID[] idFilter in them, and provide the target IDs in the idFilter...e.g.
ID remoteClient = is target for remote services lookup;
IRemoteServiceReference[] remoteRefs = rsContainerAdapter.getRemoteServiceReference(new ID[] { remoteClient}, serviceClass, null);
The xmpp test cases have been modified to use this see org.eclipse.ecf.tests.remoteservice.AbstractRemoteServiceTest.getIDFilter(), and for the XMPP tests note that it returns a non-null value (remoteClient) in
org.eclipse.ecf.tests.provider.xmpp.remoteservice.RemoteServiceTest.getIDFilter()
The existing mechanism (i.e. the use of org.eclipse.ecf.remoteservice.Constants.SERVICE_REGISTRATION_TARGETS) does still work alongside this new mechanism.
One remaining thing to do is to modify the OSGi 4.2 implementation to use the appropriate/new getRemoteServiceReferences call. I've opened bug 328192 to track this.
Now the bad news. I've noticed in testing that the Smack deadlock bug 321032 now occurs more frequently with the testing...mostly because each of the test cases tears down (calls XMPPConnection.disconnect()) many times...and this seems to make the Smack bug more likely to appear. I'm not sure what we can do about this for our automated tests...as we don't want to have this Smack bug hang Hudson. Markus...any ideas?
But in any event, I'm hopeful this should fix the xmpp-specific weaknesses once and for all, and make it a more useful remoteservices provider.
There are some issues resulting from our build not using the latest set of ECF infrastructure bundles (e.g. org.eclipse.ecf.provider and org.eclipse.ecf.tests.remoteservice...and there were a couple of small fixes in org.eclipse.ecf.provider...and one test case removal from org.eclipse.ecf.tests.remoteservice)...but I'm going to resolve this bug and we'll deal with the releng issues for ECF 3.4 over the next few days.
(In reply to comment #12) > Now the bad news. I've noticed in testing that the Smack deadlock bug 321032 > now occurs more frequently with the testing...mostly because each of the test > cases tears down (calls XMPPConnection.disconnect()) many times...and this > seems to make the Smack bug more likely to appear. I'm not sure what we can do > about this for our automated tests...as we don't want to have this Smack bug > hang Hudson. Markus...any ideas? I do not think we can do much until #321032 gets addressed. But the Hudson job C-HEAD-xmpp.feature has a build timeout defined that kills the job to make room for other jobs. (In reply to comment #13) > (In reply to comment #12) > > Now the bad news. I've noticed in testing that the Smack deadlock bug 321032 > > now occurs more frequently with the testing...mostly because each of the test > > cases tears down (calls XMPPConnection.disconnect()) many times...and this > > seems to make the Smack bug more likely to appear. I'm not sure what we can do > > about this for our automated tests...as we don't want to have this Smack bug > > hang Hudson. Markus...any ideas? > > I do not think we can do much until #321032 gets addressed. But the Hudson job > C-HEAD-xmpp.feature has a build timeout defined that kills the job to make room > for other jobs. I guess this will have to serve in the short term. Eugen...and/or others...a welcome contribution for the xmpp provider would be looking at bug 321032 (which I do believe is ultimately a Smack bug). I'm not sure if Jive is maintaining/fixing Smack in open source any longer...it might be useful to ask them...but I can't do that right now myself. The Smack version we are currently using (and has been through EF IP, etc) is 3.1.0. Another route might be to fix the bug ourselves (since we build the org.jivesoftware.smack library from source). If this is the only way to address this bug then I'm in favor (although obviously there are advantages to fixing it upstream in Smack). In any event, Eugen if you are interested this would be a good way to help (along with more xmpp remote services test code, reporting bugs, working with the committers and community on additional documentation, working with the community on a remote services test harness, etc). Thanks. (In reply to comment #14) > In any event, Eugen if you are interested this would be a good way to help > (along with more xmpp remote services test code, reporting bugs, working with > the committers and community on additional documentation, working with the > community on a remote services test harness, etc). Thanks. Hi Scott, I just checked out the ECF tests but I am not able to run them. I am not sure how to set up a working test environment for ECF and how to check in my code with Git. I'll ask Markus for help, hopefully he can give me a hand to get this things done. Eugen (In reply to comment #14) > In any event, Eugen if you are interested this would be a good way to help > (along with more xmpp remote services test code, reporting bugs, working with > the committers and community on additional documentation, working with the > community on a remote services test harness, etc). Thanks. Hi Scott, I just checked out the ECF tests but I am not able to run them. I am not sure how to set up a working test environment for ECF and how to check in my code with Git. I'll ask Markus for help, hopefully he can give me a hand to get this things done. Eugen Created attachment 181594 [details]
remote service tests
(In reply to comment #17) > Created an attachment (id=181594) [details] > remote service tests Hi Scott, I started to create remote service tests for the XMPP provider which will meet our use cases. What is the best way to contribute further tests? Should I create code attachments? Btw: your bug fixes seem to work fine so far. Eugen (In reply to comment #18) > Hi Scott, I started to create remote service tests for the XMPP provider which > will meet our use cases. What is the best way to contribute further tests? > Should I create code attachments? Since this contribution is less than 250LOC, we can add it to master right away. However from now on, please send patches rather than plain files [0]. Makes it easier for us. For bigger changes that require a couple iterations I suggest you clone git.eclipse.org/ecf/org.eclipse.ecf.git to github and share that repo with us. Once done we will then file a CQ and move it git.eclipse.org after CQ-approval. [0] http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ P.S.: The files are missing copyright headers. Is this your personal work or work funded by your employer? (In reply to comment #19) > (In reply to comment #18) > > > Hi Scott, I started to create remote service tests for the XMPP provider which > > will meet our use cases. What is the best way to contribute further tests? > > Should I create code attachments? > > Since this contribution is less than 250LOC, we can add it to master right > away. However from now on, please send patches rather than plain files [0]. > Makes it easier for us. How do I send patches? > For bigger changes that require a couple iterations I suggest you clone > git.eclipse.org/ecf/org.eclipse.ecf.git to github and share that repo with us. > Once done we will then file a CQ and move it git.eclipse.org after CQ-approval. > > [0] http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ > > P.S.: The files are missing copyright headers. Is this your personal work or > work funded by your employer? It's my personal work. Released Eugen's work to master, iplog flag set. Created attachment 181602 [details]
mylyn/context/zip
Eugen, the tests are now executed as part of the automated build. Two of them are failing though [0]. Can you look into it? [0] https://build.ecf-project.org/hudson/job/C-HEAD-xmpp.feature/27/testReport/ (In reply to comment #23) > Eugen, the tests are now executed as part of the automated build. Two of them > are failing though [0]. Can you look into it? > > [0] https://build.ecf-project.org/hudson/job/C-HEAD-xmpp.feature/27/testReport/ Hi Markus, I know that the tests are failing. If I am not mistaken they uncover some bugs within the XMPP provider. Eugen (In reply to comment #24) > Hi Markus, > > I know that the tests are failing. If I am not mistaken they uncover some bugs > within the XMPP provider. Perfect, that's what tests are for. :-) Are those bugs known already/Do we have tickets for them? Do they have to be fixed for ECF 3.4 release (show stoppers)? (In reply to comment #25) > (In reply to comment #24) > > > Hi Markus, > > > > I know that the tests are failing. If I am not mistaken they uncover some bugs > > within the XMPP provider. > > Perfect, that's what tests are for. :-) > > Are those bugs known already/Do we have tickets for them? Do they have to be > fixed for ECF 3.4 release (show stoppers)? I don't think that these bugs are real show stoppers but obviously need some investigation. I don't even know if these bugs are real bugs or maybe I didn't really get how ECF works :) So before filing bugs I would like to ask somebody to check the tests and confirm that the way I expect the XMPP provider to behave is also the ECF-way. Eugen (In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > > > Hi Markus, > > > > > > I know that the tests are failing. If I am not mistaken they uncover some bugs > > > within the XMPP provider. > > > > Perfect, that's what tests are for. :-) > > > > Are those bugs known already/Do we have tickets for them? Do they have to be > > fixed for ECF 3.4 release (show stoppers)? > > I don't think that these bugs are real show stoppers but obviously need some > investigation. I don't even know if these bugs are real bugs or maybe I didn't > really get how ECF works :) So before filing bugs I would like to ask somebody > to check the tests and confirm that the way I expect the XMPP provider to > behave is also the ECF-way. > > Eugen Hi Eugen, It would help if you would do this for all failing tests a) explain what the test is trying to do with the test (on this bug/wherever the test is attached) b) explain what is failing/how it's failing (failed assertion, exception, whatever) That way I/we/someone can understand what the test is without having to devine from the source code whether the test is faulty, or making some incorrect assumptions, or it uncovers a bug, or whatever seems to result in it's failure. Markus, in the future, let's please do the above and verify that the tests are valid *before* we add them to the automated tests. For these tests, I request that they be removed from the xmpp automated tests (on Release_3_4 if not master) until we do the above...as this week there is not time for me to spend reviewing/repairing this test code. (In reply to comment #27) > Markus, in the future, let's please do the above and verify that the tests are > valid *before* we add them to the automated tests. > > For these tests, I request that they be removed from the xmpp automated tests > (on Release_3_4 if not master) until we do the above...as this week there is > not time for me to spend reviewing/repairing this test code. The tests are not part of Release_3_4. In general I disagree about releasing only passing tests to master. Even if the tests only fail due to API misuse, they show that API can be used in unintended ways and thus are valid tests. :) And I don't see any harm in test failures in continuous builds. Isn't this the purpose of continuous builds in the first place? Iff your concern is interrupting feature development, I suggest we switch to a more advanced git development model that restricts master to product-ready work items only and uses dedicated enhancement/work item branches [0]. But IMO we need to get used to git more, before we move to such a model. [0] http://nvie.com/posts/a-successful-git-branching-model/ (In reply to comment #28) > (In reply to comment #27) > > Markus, in the future, let's please do the above and verify that the tests are > > valid *before* we add them to the automated tests. > > > > For these tests, I request that they be removed from the xmpp automated tests > > (on Release_3_4 if not master) until we do the above...as this week there is > > not time for me to spend reviewing/repairing this test code. > > The tests are not part of Release_3_4. > > In general I disagree about releasing only passing tests to master. Even if the > tests only fail due to API misuse, they show that API can be used in unintended > ways and thus are valid tests. :) But that's only if they fail due to API misuse. First, *why* they fail has to be determined...that's what I'm asking for...figuring out why they fail (whether it's a bug in the test code or bug in something else) before adding them to the automated tests. >And I don't see any harm in test failures in > continuous builds. Isn't this the purpose of continuous builds in the first > place? I would say that the main purpose of automated testing in continuous builds is to detect regression. Sure...if a new test actually *does* expose a bug...then it's fine with me if it's introduced into the automated tests...along with identifying what the bug is...but it's going to be a huge waste of time if we introduce a test and don't even know whether it exposes a bug or not...and that's the case here until someone goes through the exercise requested. Basically, without some examination/explanation of the test and cause for failure prior to introducing into the automated build, we will be spending way too much time debugging contributed test code...which is time taken away from adding new features and fixing real bugs. i.e. just because a test fails doesn't mean it's a bug of any kind in ECF...at least prior to the examination/explanation that I'm requesting. If we figure out why it's failing, and it turns out to be something in ECF then fine...we can open a bug for the issue, add the test to the automated tests, and deal with the actual issue. > > Iff your concern is interrupting feature development, I suggest we switch to a > more advanced git development model that restricts master to product-ready work > items only and uses dedicated enhancement/work item branches [0]. But IMO we > need to get used to git more, before we move to such a model. Yes, I agree that we all need to get used to it more before we move to such a model (and I and others probably would like to examine/understand that model for applicability to our situation). Practically speaking, you and I are the only committers doing any serious work with git yet. We can't change too many things at once...otherwise it will make it way too difficult for others to be involved/contribute...and force most of the work on just a few people (guess who). (In reply to comment #27) > Hi Eugen, > > It would help if you would do this for all failing tests > > a) explain what the test is trying to do with the test (on this bug/wherever > the test is attached) > b) explain what is failing/how it's failing (failed assertion, exception, > whatever) Hi folks, here some explanation: 1. testRightServiceForClients: In this use case we assume three clients 0, 1, 2 which register each an instance of IExampleService. Each client tries now to get a remote service registered by other clients e.g. client 0 tries to get services registered by client 1 & 2. The test is supposed to make sure that client 0 is able to retrieve services registered by client 1 & 2 AND if client 0 is asking for a service registered by client 1 the appropriate service will be returned and not accidentally a wrong one, from client 2. The code for this test is: // Client 0 is asking for a remote service registered by client 1 IExampleService remoteService1 = getClient(0).getRemoteService( getClient(1)); assertNotNull(remoteService1); // assure that the returned service was registered by client 1. IExampleService has a method getClientID() to identify the client which registered a service assertEquals(getClient(1).getClientID(), remoteService1.getClientID()); // compare two XMPP-IDs This assertion fails with the following exception: org.osgi.framework.ServiceException: Service exception on remote service proxy rsid=org.eclipse.ecf.remoteservice.RemoteServiceID[containerID=XMPPID[xmpps://ecf-test1@ecf-project.org/ecf.jwkUIvxMT7TB/OgrzKMTy3qysig=];containerRelativeID=1] at org.eclipse.ecf.remoteservice.AbstractRemoteService.invoke(AbstractRemoteService.java:185) at $Proxy0.getClientID(Unknown Source) at org.eclipse.ecf.tests.provider.xmpp.remoteservice.RemoteServiceRetrieval.testRightServiceForClients(RemoteServiceRetrieval.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383) Caused by: org.eclipse.ecf.core.util.ECFException: Request timed out after 30000ms at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.callSynch(RegistrySharedObject.java:898) at org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceImpl.callSync(RemoteServiceImpl.java:55) at org.eclipse.ecf.remoteservice.AbstractRemoteService.invokeSync(AbstractRemoteService.java:148) at org.eclipse.ecf.remoteservice.AbstractRemoteService.invoke(AbstractRemoteService.java:180) ... 39 more Caused by: org.eclipse.equinox.concurrent.future.TimeoutException ... 43 more 2. testConnectAndDisconnectClients: We assume again three clients 0-2. Each client registered the IExampleService as a remote service. Now in an XMPP environment clients can come and go at any time. This tests tries to make sure that if clients are gone the service they provide is no longer available. And at times they come back the service is available again. The code is: // Client 0 tries to get service from client 1 IExampleService remoteService1 = getClient(0).getRemoteService( getClient( assertNotNull(remoteService1); // disconnect client 1, the services client 1 registered should no longer be available. getClient(1).disconnect(); // client 0 tries to retrieve a service from a disconnected client 1. This should not be possible. IExampleService remoteService2 = getClient(0).getRemoteService( getClient(1)); assertNull(remoteService2); This assertion fails with the following failure trace: junit.framework.AssertionFailedError: Expected: <null> but was: org.eclipse.ecf.tests.provider.xmpp.remoteservice.IExampleService.proxy@org.eclipse.ecf.remoteservice.RemoteServiceID[containerID=XMPPID[xmpps://ecf-test1@ecf-project.org/ecf.FbZx1Ilhr9wRUpETLpBYgEdjTKA=];containerRelativeID=4] at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNull(Assert.java:233) at junit.framework.Assert.assertNull(Assert.java:226) at org.eclipse.ecf.tests.provider.xmpp.remoteservice.RemoteServiceRetrieval.testConnectAndDisconnectClients(RemoteServiceRetrieval.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383) I hope this helps. Eugen Hi Eugen, First, thanks for the explanation. (In reply to comment #30) > (In reply to comment #27) <stuff deleted> > here some explanation: > > 1. testRightServiceForClients: > In this use case we assume three clients 0, 1, 2 which register each an > instance of IExampleService. Each client tries now to get a remote service > registered by other clients e.g. client 0 tries to get services registered by > client 1 & 2. The test is supposed to make sure that client 0 is able to > retrieve services registered by client 1 & 2 AND if client 0 is asking for a > service registered by client 1 the appropriate service will be returned and not > accidentally a wrong one, from client 2. The code for this test is: > > // Client 0 is asking for a remote service registered by client 1 > IExampleService remoteService1 = getClient(0).getRemoteService( > getClient(1)); > assertNotNull(remoteService1); > > // assure that the returned service was registered by client 1. IExampleService > has a method getClientID() to identify the client which registered a service > assertEquals(getClient(1).getClientID(), remoteService1.getClientID()); // > compare two XMPP-IDs > Ok...I've examined the test code, and I believe this first problem is because in org.eclipse.ecf.tests.provider.xmpp.remoteservice.RemoteServiceRetrieval.XMPPClient.getRemoteService(XMPPClient) You had the following code: IRemoteServiceReference[] remoteServiceReferences = adapter.getRemoteServiceReferences(toClient.getClientID(),IExampleService.class.getName(), null); When I change this to: IRemoteServiceReference[] remoteServiceReferences = adapter.getRemoteServiceReferences(new ID[] { toClient.getClientID() },IExampleService.class.getName(), null); The testRightServiceForClients test succeeds. The reason for this is that the ID[] is the set of targets for the remote service reference lookup. The version getRemoteServiceReferences(ID,String,Dictionary) (that you were using originally), doesn't use the newly introduced behavior of lazily looking up the remote service reference. I will fix this in the test code. In general, to use this 'lazy' lookup for xmpp, it's necessary to use one of the getRemoteServiceReference methods that includes the ID[] (idFilter) parameter. > > 2. testConnectAndDisconnectClients: This test identifies another limitation with the xmpp provider, and that's that there is no notification of a remote client's disconnection, so no way to clean up the remote service registry based upon the disconnection/departure of remote clients. I believe this test is failing because no notification of disconnect is received, and so the clients can't clean up properly. I'll look at this and see what can be done in the short term. In the mean time, I'll reopen this bug...to be able to track progress and discuss. Released fix for issue described in comment 31 to master. Resolving as fixed. Note that several changes were made to the RemoteServiceRetrieve test cases...to unregister rather than disconnect...but the additions to RemoteServiceRegistry now support unregistration using the xmpp provider model of remote service access. All xmpp tests now pass for me locally (including the ones attached to this bug). This commit should be merged into the Release_3_4 branch for inclusion into the 3.4 release. Markus, would you be willing to do that? I don't have the git command line client working yet, and am not at all confident about this being done correctly with the eGit client...and my own limited experience with git. The commit is here: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=588ad10826f9b5fef1667e2b992e44818d0e96aa (In reply to comment #32) > This commit should be merged into the Release_3_4 branch for inclusion into the > 3.4 release. Markus, would you be willing to do that? I don't have the git > command line client working yet, and am not at all confident about this being > done correctly with the eGit client...and my own limited experience with git. Given that all diffs between master and Release_3_4 were changes in incubation I have simply merged master and Release_3_4. http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?h=Release_3_4&id=5bb64eff68332551875274f42f2235b2084570e2 -- // pull master as well as Release_3_4 first git checkout Release_3_4 git merge --no-ff master git push origin Release_3_4 FWIW: For picking out individual commits, [0] shows ways to do it. [0] http://gitready.com/intermediate/2009/03/04/pick-out-individual-commits.html (In reply to comment #32) > All xmpp tests now pass for me locally (including the ones attached to this > bug). https://build.ecf-project.org/hudson/job/C-HEAD-xmpp.feature/30/ marks a successful test run for master. |
In using the xmpp provider for remote services this bug was reported adapter.registerRemoteService(new String[] { serviceName }, impl, props); Calling this method caused the following exception: org.eclipse.ecf.core.identity.IDCreateException: Exception creating remoteID at org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceNamespace.createInstance(RemoteServiceNamespace.java:39) at org.eclipse.ecf.core.identity.IDFactory.createID(IDFactory.java:211) at org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistryImpl.createRemoteServiceID(RemoteServiceRegistryImpl.java:207) at org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistrationImpl.publish(RemoteServiceRegistrationImpl.java:81) at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.registerRemoteService(RegistrySharedObject.java:347) at org.remotercp.ecf.session.impl.SessionServiceImpl.registerRemoteService(SessionServiceImpl.java:218) at org.remotercp.ecf.session.impl.SessionServiceImpl.publishRemoteServicesToUser(SessionServiceImpl.java:331) at org.remotercp.ecf.session.impl.SessionServiceImpl.access$2(SessionServiceImpl.java:321) at org.remotercp.ecf.session.impl.SessionServiceImpl$1.handlePresence(SessionServiceImpl.java:298) at org.eclipse.ecf.internal.provider.xmpp.XMPPContainerPresenceHelper.firePresenceListeners(XMPPContainerPresenceHelper.java:568) at org.eclipse.ecf.internal.provider.xmpp.XMPPContainerPresenceHelper.handlePresenceEvent(XMPPContainerPresenceHelper.java:557) at org.eclipse.ecf.internal.provider.xmpp.XMPPContainerPresenceHelper.handleEvent(XMPPContainerPresenceHelper.java:135) at org.eclipse.ecf.provider.generic.SOWrapper.svc(SOWrapper.java:185) at org.eclipse.ecf.provider.generic.SOWrapper$2.run(SOWrapper.java:138) at java.lang.Thread.run(Thread.java:637) Hunting down the problem I realized that the class RemoteServiceRegistryImpl apparently caused the exception within the method: public IRemoteServiceID createRemoteServiceID(long serviceid) { return (IRemoteServiceID) IDFactory.getDefault().createID(IDFactory.getDefault().getNamespaceByName(RemoteServiceNamespace.NAME), new Object[] {containerID, new Long(serviceid)}); } The parameter containerID is null. Diving in the ECF code the problem seems to be within the class ClientSOContainer. The method: public ID getConnectedID() { return remoteServerID; }