Bugzilla – Full Text Bug Listing
| Summary: | Problem registering and/or finding remote services | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Matt Sither <sither> | ||||
| Component: | ecf.remoteservices | Assignee: | Scott Lewis <slewis> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | bugs.eclipse.org, codesurgeon, slewis, wim.jongman | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Matt Sither
Could you attempt to reproduce this on a more recent build? A great deal has changed in the the remote service implementation...both for the xmpp provider and in the infrastructure since 20090831 build. Note you can get the most recent build for Helios contribution here (p2 repo): http://download.eclipse.org/rt/ecf/3.3/helios/site.p2 Thanksinadvance. (In reply to comment #0) > Build Identifier: ECF 3.0.0.v20090831 > > I have a simple example using the remote services API with XMPP (specifically, > XMPPS via Google). My application logs in to a GMail account and registers a > service. When I run two instances of the application on one computer, each > instance is able to find an IRemoteServiceReference to the other. But when I > run two instances of the application on two separate machines, one of them is > able to find a reference to the other, but not the other way around. I > apologize that I don't have any more information. No exceptions are thrown, > and I didn't notice anything suspect when I stepped through > IRemoteServiceContainerAdapter.getRemoteServiceReferences(). > > Also, I'm not sure if this is significant, but when I call > getRemoteServiceReferences(), I actually do get an IRemoteServiceReference, but > it's a pointer to my own remote service, not the other user's remote service. > > Reproducible: Always > > Steps to Reproduce: > 1. Set up a remote service (call it RS1) on machine 1. > 2. Set up a remote service (call it RS2) on machine 2. > 3. Try to look up RS1 from machine 2 and RS2 from machine 1. > 4. One of the lookups will work, and the other will not. Thanks for the quick response! I updated our copy of ECF with the build you recommended, and oddly enough, the problem persists. However, the problem now occurs even if both applications are running on the same machine, and it happens in both directions. Now I'm able to step through the code and see why this is happening. Basically, it seems the XMPP ID's don't match perfectly. When I attempt to look up client 2's remote service, I get client 2's ID from my roster: XMPPID[xmpps://xxx@gmail.com/ecf.AQdkjuDE74DFCE]. The problem is that the remote service is mapped in my registry under a slightly different ID: XMPPSID[xmpps://xxx@gmail.com/ecf.AQdkjuasbqtkomHCT2tLeqb4v8U=]. Does this make sense? I'm considering a nasty workaround where I enumerate all remote services and manually compare the ID's (possibly by comparing ID.getName()), but I'd like to do it right, so do you see anything that I'm blatantly doing wrong? Is it expected that the ID I get from the roster is slightly different from the ID in the remote service registry? I didn't expect them to be different because they represent the same user, but maybe I'm missing something. (In reply to comment #2) > Thanks for the quick response! I updated our copy of ECF with the build you > recommended, and oddly enough, the problem persists. However, the problem now > occurs even if both applications are running on the same machine, and it > happens in both directions. Now I'm able to step through the code and see why > this is happening. Basically, it seems the XMPP ID's don't match perfectly. > When I attempt to look up client 2's remote service, I get client 2's ID from > my roster: XMPPID[xmpps://xxx@gmail.com/ecf.AQdkjuDE74DFCE]. The problem is > that the remote service is mapped in my registry under a slightly different ID: > XMPPSID[xmpps://xxx@gmail.com/ecf.AQdkjuasbqtkomHCT2tLeqb4v8U=]. Does this > make sense? XMPP IDs have the notion of a 'resource'...i.e. the segment after the xxx@gmail.com...e.g. ecf.AQdkjuasbqtkomHCT2tLeqb4v8U= This last segment is part of XMPP that allows more than one client to be connected to a given account...so they can be unambiguously identified. > > I'm considering a nasty workaround where I enumerate all remote services and > manually compare the ID's (possibly by comparing ID.getName()), but I'd like to > do it right, so do you see anything that I'm blatantly doing wrong? Is it > expected that the ID I get from the roster is slightly different from the ID in > the remote service registry? I didn't expect them to be different because they > represent the same user, but maybe I'm missing something. Are you using the same account with two clients? Or are you using two accounts? It's possible that there is some problem with the XMPP ID handling, but it would be good to know how you are using things here so as to help diagnose. > XMPP IDs have the notion of a 'resource'...i.e. the segment after the > xxx@gmail.com...e.g. ecf.AQdkjuasbqtkomHCT2tLeqb4v8U= > > This last segment is part of XMPP that allows more than one client to be > connected to a given account...so they can be unambiguously identified. > I'm aware of XMPP's use of resource identifiers, but I'm only logged into the account once. It seems that this one login might have generated two separate resource identifiers, one that shows up in my roster and one that shows up in my remote service registry. Also, I don't know if this matters, but the ID I get from the roster is a XMPPID, and the ID I get from the remote service registry is a XMPPSID. > > Are you using the same account with two clients? Or are you using two > accounts? It's possible that there is some problem with the XMPP ID handling, > but it would be good to know how you are using things here so as to help > diagnose. Two different accounts. Let's say client 1 logs into xxx@gmail.com, and client 2 logs into yyy@gmail.com. xxx and yyy are in each other's buddy lists, so when I attempt to look up the remote service of yyy from client 1, I'm grabbing yyy's ID from the roster. (In reply to comment #4) > > XMPP IDs have the notion of a 'resource'...i.e. the segment after the > > xxx@gmail.com...e.g. ecf.AQdkjuasbqtkomHCT2tLeqb4v8U= > > > > This last segment is part of XMPP that allows more than one client to be > > connected to a given account...so they can be unambiguously identified. > > > > I'm aware of XMPP's use of resource identifiers, but I'm only logged into the > account once. It seems that this one login might have generated two separate > resource identifiers, one that shows up in my roster and one that shows up in > my remote service registry. This is entirely unexpected. I don't really even know how it could happen. Is this easily reproducible in your environment? If so, I would appreciate some further help isolating the problem. Could you try the following: set the smack debug flag by setting this system property: -Dsmack.debug=true When the xmpp provider is connected, this should result in the smack debug window appearing, and producing xml output of the actual traffic going into/out of each client. You probably should paste that output here/publicly, but if you can I would appreciate sending to slewis at composent.com. We changed to Smack 3.1 in fall of 2009, and my only initial thought is that it could be something having to do with that (i.e. bug in our code, bug in theirs, or some new interaction). >Also, I don't know if this matters, but the ID I > get from the roster is a XMPPID, and the ID I get from the remote service > registry is a XMPPSID. Hmmm. This is unexpected as well. Ok...if you are game we will try to track this down...it may take some time, however, as we (ECF) are in the last throws of our Helios release preparation...so please be patient. I started to test with smack.debug=true, but I noticed something else that's probably the problem. I stepped through the call to registerRemoteService(), and apparently this fails. The ID argument at the top of the stack trace below is null, and ECFConnection.sendMessage throws an IOException when the ID arg is null. So the registration never happens. To see why the ID is null, trace the stack back to the ">>" below. RegistrySharedObject.registerRemoteService actually passes a null ID to sendAddRegistration. This null ID is passed all the way to the top of the stack trace, where it throws the IOException.
Let me know if I can provide any more information. I'm happy to help track this bug down.
Thread [main] (Suspended)
ECFConnection.sendMessage(ID, Message) line: 321
ECFConnection.sendAsynch(ID, byte[]) line: 316
XMPPSContainer(ClientSOContainer).queueContainerMessage(ContainerMessage) line: 311
XMPPSContainer(SOContainer).sendMessage(ContainerMessage) line: 937
XMPPSContainer(ClientSOContainer).sendMessage(ContainerMessage) line: 363
XMPPSContainer(SOContainer).sendSharedObjectMessage(ID, ID, Serializable) line: 1013
XMPPSContainer(ClientSOContainer).sendSharedObjectMessage(ID, ID, Serializable) line: 435
XMPPSContainer(SOContainer).sendMessage(ID, ID, Object) line: 1009
XMPPSContainer(ClientSOContainer).sendMessage(ID, ID, Object) line: 427
XMPPContainerContext(SOContext).sendMessage(ID, Object) line: 230
XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(BaseSharedObject).sendSharedObjectMsgTo(ID, SharedObjectMsg) line: 358
XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(RegistrySharedObject).sendAddRegistration(ID, Integer, RemoteServiceRegistrationImpl) line: 707
>> XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(RegistrySharedObject).sendAddRegistration(ID, RemoteServiceRegistrationImpl) line: 701
>> XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(RegistrySharedObject).registerRemoteService(String[], Object, Dictionary) line: 263
RpcService.getRemoteRpcService(ID) line: 58
RpcService.getRemoteRpc(ID, boolean) line: 90
RpcService.getRemote(ID, Class<T>, boolean) line: 110
EtmClient.getRemoteAdapterAsync(ID, Class<T>) line: 213
SharedContextManager.sendObject(ID, IContext) line: 140
DndCardHandler$InnerImportable.handle(IRosterEntry, IContext) line: 67
DndCardHandler$InnerImportable.importCard(int, int, IContext) line: 48
CardImporter.importData(int, int, Object) line: 43
DropAdapter$1.run() line: 87
RunnableLock.run() line: 35
UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134
Display.runAsyncMessages(boolean) line: 3855
Display.readAndDispatch() line: 3476
Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2405
Workbench.runUI() line: 2369
Workbench.access$4(Workbench) line: 2221
Workbench$5.run() line: 500
Realm.runWithDefault(Realm, Runnable) line: 332
Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 493
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149
EtmApplication.start(IApplicationContext) line: 59
EclipseAppHandle.run(Object) line: 194
EclipseAppLauncher.runApplication(Object) line: 110
EclipseAppLauncher.start(Object) line: 79
EclipseStarter.run(Object) line: 368
EclipseStarter.run(String[], Runnable) line: 179
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
Main.invokeFramework(String[], URL[]) line: 559
Main.basicRun(String[]) line: 514
Main.run(String[]) line: 1311
Main.main(String[]) line: 1287
(In reply to comment #6) Hi Matt. First, thanks for the help in tracking this down. It's appreciated. > I started to test with smack.debug=true, but I noticed something else that's > probably the problem. I stepped through the call to registerRemoteService(), > and apparently this fails. The ID argument at the top of the stack trace below > is null, and ECFConnection.sendMessage throws an IOException when the ID arg is > null. So the registration never happens. To see why the ID is null, trace the > stack back to the ">>" below. RegistrySharedObject.registerRemoteService > actually passes a null ID to sendAddRegistration. This null ID is passed all > the way to the top of the stack trace, where it throws the IOException. > > Let me know if I can provide any more information. I'm happy to help track > this bug down. First, from looking at the source code in CVS, it looks to me like you are somehow still using an old version of RegistrySharedObject (perhaps other classes/plugins as well, but I think RegistrySharedObject is the immediate focus of interest). When I look on line 263, 701, or 707 from RegistrySharedObject in cvs/HEAD/latest I don't see the methods given in your stack trace below. Could you load (at least) the latest version of the source into your workspace and re-run with this code (e.g. under the Eclipse debugger?). There's a project set file for getting all ECF sdk projects into workspace. Here is instructions for getting/using it: http://www.eclipse.org/ecf/dev_resources.php Alternatively, you can load just the org.eclipse.ecf.provider.remoteservice bundle in your workspace...it's located here: :pserver:anonymous@dev.eclipse.org:/cvsroot/rt module: org.eclipse.ecf/providers/bundles/org.eclipse.ecf.provider.remoteservice Another thought: The XMPP remote service provider (implementation in RegistrySharedObject is a little unusual...in that with a normal XMPP connection there is not really a context for interaction with other XMPP users...that is, when a remote service is registered (i.e. registerRemoteService called), there is not a clear set of receivers defined to send the sendAddRegistration message to. One possibility is to send to all members on roster, but that could be kind of intrusive...so we don't do that yet (but it may be an option in the future). In any event, to get around this, we allow the service registration properties to contain the targets (ID[]) for a given service registration...and in the more recent src for registerRemoteService, is this code: ... final ID[] targets = getTargetsFromProperties(properties); if (targets == null) sendAddRegistrations(null, null, new RemoteServiceRegistrationImpl[] {reg}); else for (int i = 0; i < targets.length; i++) sendAddRegistrations(targets[i], null, new RemoteServiceRegistrationImpl[] {reg}); ... inside the getTargetsFromProperties method is code that looks at the value of this service property: org.eclipse.ecf.remoteservice.Constants.SERVICE_REGISTRATION_TARGETS = "ecf.rsvc.reg.targets"; *If this service property is set* to an ID[], an ID, the value returned from getTargetsFromProperties will be non-null, and the sendAddRegistrations will be sent *to the given targets* (and sendAddRegistrations will not be given a null first parameter...which is what seems to be happening in your case...although like I said I think your source is somewhat old). So, what this lets you do is to do something like this when registering your remote service: ID[] targets = new ID[] { targetIDFromRosterOrElsewhere }; Dictionary properties = new Properties(); properties.put(org.eclipse.ecf.remoteservice.Constants.SERVICE_REGISTRATION_TARGETS, targets); adapter.registerRemoteService(svcClasses, remoteServiceObject, properties); Are you using this SERVICE_REGISTRATION_TARGETS property when registering your remote service? It's possible you are and that there is some other bug with your use case...and with the latest source code I think we'll be able to track it down and fix. Thanks. > > Thread [main] (Suspended) > ECFConnection.sendMessage(ID, Message) line: 321 > ECFConnection.sendAsynch(ID, byte[]) line: 316 > XMPPSContainer(ClientSOContainer).queueContainerMessage(ContainerMessage) > line: 311 > XMPPSContainer(SOContainer).sendMessage(ContainerMessage) line: 937 > XMPPSContainer(ClientSOContainer).sendMessage(ContainerMessage) line: 363 > XMPPSContainer(SOContainer).sendSharedObjectMessage(ID, ID, Serializable) > line: 1013 > XMPPSContainer(ClientSOContainer).sendSharedObjectMessage(ID, ID, > Serializable) line: 435 > XMPPSContainer(SOContainer).sendMessage(ID, ID, Object) line: 1009 > XMPPSContainer(ClientSOContainer).sendMessage(ID, ID, Object) line: 427 > XMPPContainerContext(SOContext).sendMessage(ID, Object) line: 230 > > XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(BaseSharedObject).sendSharedObjectMsgTo(ID, > SharedObjectMsg) line: 358 > > XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(RegistrySharedObject).sendAddRegistration(ID, > Integer, RemoteServiceRegistrationImpl) line: 707 > >> XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(RegistrySharedObject).sendAddRegistration(ID, RemoteServiceRegistrationImpl) line: 701 > >> XMPPRemoteServiceAdapterFactory$XMPPRegistrySharedObject(RegistrySharedObject).registerRemoteService(String[], Object, Dictionary) line: 263 > RpcService.getRemoteRpcService(ID) line: 58 > RpcService.getRemoteRpc(ID, boolean) line: 90 > RpcService.getRemote(ID, Class<T>, boolean) line: 110 > EtmClient.getRemoteAdapterAsync(ID, Class<T>) line: 213 > SharedContextManager.sendObject(ID, IContext) line: 140 > DndCardHandler$InnerImportable.handle(IRosterEntry, IContext) line: 67 > DndCardHandler$InnerImportable.importCard(int, int, IContext) line: 48 > CardImporter.importData(int, int, Object) line: 43 > DropAdapter$1.run() line: 87 > RunnableLock.run() line: 35 > UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134 > Display.runAsyncMessages(boolean) line: 3855 > Display.readAndDispatch() line: 3476 > Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2405 > Workbench.runUI() line: 2369 > Workbench.access$4(Workbench) line: 2221 > Workbench$5.run() line: 500 > Realm.runWithDefault(Realm, Runnable) line: 332 > Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 493 > PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 > EtmApplication.start(IApplicationContext) line: 59 > EclipseAppHandle.run(Object) line: 194 > EclipseAppLauncher.runApplication(Object) line: 110 > EclipseAppLauncher.start(Object) line: 79 > EclipseStarter.run(Object) line: 368 > EclipseStarter.run(String[], Runnable) line: 179 > NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not > available [native method] > NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 > DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 > Method.invoke(Object, Object...) line: 597 > Main.invokeFramework(String[], URL[]) line: 559 > Main.basicRun(String[]) line: 514 > Main.run(String[]) line: 1311 > Main.main(String[]) line: 1287 Hey Scott, I think I figured out when the ID inconsistency first occurs. When I initially log in, the following packet is sent to the server to set my resource identifier to "ecf.2t/qcSc8bHUzbZxI9QU/fzxkcVI=":
<iq id="6286O-0" type="set">
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
<resource>ecf.2t/qcSc8bHUzbZxI9QU/fzxkcVI=</resource>
</bind>
</iq>
But the response gives me the different identifier, "ecf.2t/qcS808BE61D":
<iq id="6286O-0" type="result">
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
<jid>xxx@gmail.com/ecf.2t/qcS808BE61D</jid>
</bind>
</iq>
The second resource identifier is what the other user sees in the roster, but the first identifier is what the remote service is registered under. So when I run my software, it obtains xxx@gmail.com/ecf.2t/qcS808BE61D from the roster, but it needs to pass xxx@gmail.com/ecf.2t/qcSc8bHUzbZxI9QU/fzxkcVI= to the remote service container to find the remote service.
Let me know if you need any more information.
Sorry that my previous post (Comment 6) may have sidetracked us a bit. I'm not sure if that's actually a bug or if I just misinterpretted the docs. Either way, it seems that the mismatched ID's are probably the more critical problem.
Hi Matt, (In reply to comment #8) > Hey Scott, I think I figured out when the ID inconsistency first occurs. When > I initially log in, the following packet is sent to the server to set my > resource identifier to "ecf.2t/qcSc8bHUzbZxI9QU/fzxkcVI=": > > <iq id="6286O-0" type="set"> > <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"> > <resource>ecf.2t/qcSc8bHUzbZxI9QU/fzxkcVI=</resource> > </bind> > </iq> > > But the response gives me the different identifier, "ecf.2t/qcS808BE61D": > > <iq id="6286O-0" type="result"> > <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"> > <jid>xxx@gmail.com/ecf.2t/qcS808BE61D</jid> > </bind> > </iq> This is unexpected...and it's not clear to me whether it's permitted by the XMPP spec (since I don't have that part of the spec memorized :). For some reason that eludes me, the gmail xmpp server apparently changes the content of the jid. It's particularly strange that it doesn't change it randomly, but seems to only change the part after ecf.2t/qcS. Very strange. In any event, fixing this for gtalk xmpp is going to take some additional investigation...and figuring out some way of dealing with it in some workable manner. (In reply to comment #9) > Hi Matt, > > (In reply to comment #8) > > Hey Scott, I think I figured out when the ID inconsistency first occurs. When > > I initially log in, the following packet is sent to the server to set my > > resource identifier to "ecf.2t/qcSc8bHUzbZxI9QU/fzxkcVI=": > > > > <iq id="6286O-0" type="set"> > > <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"> > > <resource>ecf.2t/qcSc8bHUzbZxI9QU/fzxkcVI=</resource> > > </bind> > > </iq> > > > > But the response gives me the different identifier, "ecf.2t/qcS808BE61D": > > > > <iq id="6286O-0" type="result"> > > <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"> > > <jid>xxx@gmail.com/ecf.2t/qcS808BE61D</jid> > > </bind> > > </iq> > > This is unexpected...and it's not clear to me whether it's permitted by the > XMPP spec (since I don't have that part of the spec memorized :). For some > reason that eludes me, the gmail xmpp server apparently changes the content of > the jid. It's particularly strange that it doesn't change it randomly, but > seems to only change the part after ecf.2t/qcS. Very strange. > > In any event, fixing this for gtalk xmpp is going to take some additional > investigation...and figuring out some way of dealing with it in some workable > manner. Interesting. Maybe this is just a Google issue. If you or anyone else is interested, I have a workaround: public static IRemoteService getRemoteService(IRemoteServiceContainerAdapter adapter, ID user, Class<?> type) { adapter.getRemoteServiceReferences(user, type.getName(), null); IRemoteServiceReference[] refs = adapter.getAllRemoteServiceReferences(type.getName(), null); if (refs != null) { for (IRemoteServiceReference ref : refs) { if (user.getName().equalsIgnoreCase(ref.getContainerID().getName())) { return adapter.getRemoteService(ref); } } } return null; } This is far from perfect and probably not how it was intended to be used, but it does the trick. To explain, the first line sends a remote service request to the user (the request is only made the first time), which puts a reference to the service in my local registry. The next line gets a copy of all remote service references in my local registry (which now includes the reference to the given user's remote service). Then I find the service whose ID.getName() matches getName() of the given user. Let me know if there's anything else I can do to help. Created attachment 171448 [details]
Fix for gmail handling of jabber id
This patch fixes the underlying XMPPID problem by resetting the resource on the XMPPID based upon the value returned from the XMPP server in response to login in the bind iq result.
If we can get another committer (e.g. Markus...who is on bug) to review and approve this fix, we might be able to get into Helios via a new contribution this week. Just to warn you Matt...we might not have time to do this, and so it may have to wait until after Helios. But, I believe this does fix the issue generally, so if you would please apply this patch and report local testing results for your use case it would be appreciated.
I'm going to raise this bug to major...as since most people use gmail/google talk the effect of this issue will be pretty significant.
Markus if you can review and approve application to HEAD it would be appreciated.
(In reply to comment #11) > Markus if you can review and approve application to HEAD it would be > appreciated. The earliest I can do a review is in ~18h from now and I do not consider myself an expert on this part of ECF. So you might wanna ask a committer who is more knowledgeable WRT XMPP. Since the patch changes the XMPP provider it might be worthwhile to get the XMPP unit tests up and running first. Unfortunately I have not heard back from Mustafa yet regarding the XMPP test infrastructure. Can somebody else offer a XMPP server (+ a couple accounts) to run unit tests against? (In reply to comment #13) > Since the patch changes the XMPP provider it might be worthwhile to get the > XMPP unit tests up and running first. Unfortunately I have not heard back from > Mustafa yet regarding the XMPP test infrastructure. Can somebody else offer a > XMPP server (+ a couple accounts) to run unit tests against? I don't disagree with you about getting the unit tests (and xmpp server) going, but just for the record I have successfully tested the unit tests against two accounts on google talk. (In reply to comment #11) > Created an attachment (id=171448) [details] > Fix for gmail handling of jabber id > > This patch fixes the underlying XMPPID problem by resetting the resource on the > XMPPID based upon the value returned from the XMPP server in response to login > in the bind iq result. > > If we can get another committer (e.g. Markus...who is on bug) to review and > approve this fix, we might be able to get into Helios via a new contribution > this week. Just to warn you Matt...we might not have time to do this, and so > it may have to wait until after Helios. But, I believe this does fix the issue > generally, so if you would please apply this patch and report local testing > results for your use case it would be appreciated. > > I'm going to raise this bug to major...as since most people use gmail/google > talk the effect of this issue will be pretty significant. > > Markus if you can review and approve application to HEAD it would be > appreciated. Scott, thanks for sending the patch. But you'll have to excuse my ignorance. I don't know how to apply it locally. Are there any docs that explain how to do this? If I can apply the patch, I'll let you know how my local testing goes. (In reply to comment #15) > Scott, thanks for sending the patch. But you'll have to excuse my ignorance. > I don't know how to apply it locally. Are there any docs that explain how to > do this? If I can apply the patch, I'll let you know how my local testing > goes. If you have the corresponding project imported into your Eclipse workspace, you will find "apply patch" under the "team" context menu of the project. It is even easier if you have Mylyn installed and this bug open. WRT XMPP test infrastructure: nevada.codesurgeon.com is running a plain vanilla ejabberd instance. I have enabled in-band registration. Fire up your favorite IM client, e.g. Adium on OS X, create a new account and request registration on the server. Pick your username and password as desired. Please LMK if you're intending to put heavy load on the server, i.e. something along the lines of several tenths of new simultaneous users. Feel free to use the server for XMPP and Wave testing purposes. Build 113 [0] will use Mustafa's XMPP server. [0] https://build.ecf-project.org/hudson/job/L-HEAD-sdk.tests.feature/113/ > Scott, thanks for sending the patch. But you'll have to excuse my ignorance.
> I don't know how to apply it locally. Are there any docs that explain how to
> do this? If I can apply the patch, I'll let you know how my local testing
> goes.
Just open the patch in a text editor. Select all and copy to clipboard. Then go to the team submenu of the package explorer context menu and select "Apply Patch" and follow the wizard.
Released proposed patch to HEAD (ECF 3.4 stream). All my tests indicate the patch fixes the issue caused by google service behavior. If the problem experienced by this bug is not fixed, please reopen this bug. Note this fix will not be released until ECF 3.4 (and I don't currently have a date for ECF 3.4 release, but guess would be Sept 2010). Resolving as fixed. Also applied to Release_3_3 stream, for deployment as 3.3.1. |