Bugzilla – Full Text Bug Listing
| Summary: | User presence won't be updated | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Eugen Reiswich <reiswich> | ||||
| Component: | ecf.presence | Assignee: | ecf.core-inbox <ecf.core-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | reiswich, slewis | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Question: What XMPP server/service are you using? What are the two accounts (A and B)? Do you have the means to try this out with some other service/server? If so do you see the same thing? If you would, it would be great if you would start both clients with the Smack XMPP debugger...which shows the XMPP-level protocol/traffic. To start with this debugging enabled, simply add this as a vm argument (to Eclipse command line, or command line of your app): -Dsmack.debug=true When your client connects, the smack debugger should come up and show you the xml traffic/messages between each client and the server. If you are able to capture this traffic, and attach it to this bug (for both A and B clients if possible) it could prove very helpful. If you do this, please be sure to remove/wipe out the password information for the two accounts A and B from your captured debug output (it will be in the login message when the clients first connect). Thanks. (In reply to comment #1) > Question: > > What XMPP server/service are you using? What are the two accounts (A and B)? > > Do you have the means to try this out with some other service/server? If so do > you see the same thing? > > If you would, it would be great if you would start both clients with the Smack > XMPP debugger...which shows the XMPP-level protocol/traffic. To start with > this debugging enabled, simply add this as a vm argument (to Eclipse command > line, or command line of your app): > > -Dsmack.debug=true > > When your client connects, the smack debugger should come up and show you the > xml traffic/messages between each client and the server. If you are able to > capture this traffic, and attach it to this bug (for both A and B clients if > possible) it could prove very helpful. If you do this, please be sure to > remove/wipe out the password information for the two accounts A and B from your > captured debug output (it will be in the login message when the clients first > connect). > > Thanks. Hi Scott, I am using the Open Source server jabber-server.de (OpenFire). Account A: user sandra pw sandra Account B: user dima pw dima These are accounts just to play a bit around so you can use them. > Do you have the means to try this out with some other service/server? If so do > you see the same thing? I tried this out with a different server and indeed it behaves different. Now user A and B go get all the information, but when I log in a third user C the odd behavior starts. Sometimes user B doesn't get all the information, sometimes user A. ************************************** Here are the XMPP logs for user dima: <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="jabber-server.de" id="2314f3b9" xml:lang="en" version="1.0"> <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>JIVE-SHAREDSECRET</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms></stream:features> <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="jabber-server.de" id="2314f3b9" xml:lang="en" version="1.0"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>JIVE-SHAREDSECRET</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="http://jabber.org/features/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/></stream:features> <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/> <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="jabber-server.de" id="2314f3b9" xml:lang="en" version="1.0"><stream:features><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features> <iq type="result" id="Hi04F-0" to="jabber-server.de/2314f3b9"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>dima@jabber-server.de/1276789248947</jid></bind></iq> <iq type="result" id="Hi04F-1" to="dima@jabber-server.de/1276789248947"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq> <iq type="result" id="Hi04F-2" to="dima@jabber-server.de/1276789248947"><query xmlns="jabber:iq:roster"><item jid="sandra@jabber-server.de" name="Sandra" subscription="to"><group>Friends</group><group>Technik</group></item><item jid="spiderman@jabber-server.de" name="Spiderman" subscription="to"><group>Friends</group></item><item jid="jabber-server.de\20support@jabber-server.de" name="Jabber-Server.de Support" subscription="to"><group>Jabber-Server.de Support</group></item><item jid="john@jabber-server.de" name="John" subscription="both"><group>Friends</group><group>Technik</group></item><item jid="klaus@jabber-server.de" name="Klaus" subscription="both"><group>Technik</group></item><item jid="desyadmin@jabber-server.de" name="desyadmin" subscription="both"><group>Friends</group></item></query></iq> <presence id="0er0j-3" from="sandra@jabber-server.de/1276789229134" to="dima@jabber-server.de/1276789248947"><x xmlns="vcard-temp:x:update"><photo></photo></x></presence> <presence from="jabber-server.de\20support@jabber-server.de/d3dc03d9" to="dima@jabber-server.de/1276789248947"><priority>1</priority><c xmlns="http://jabber.org/protocol/caps" node="http://pidgin.im/" hash="sha-1" ver="I22W7CegORwdbnu0ZiQwGpxr0Go="/><x xmlns="vcard-temp:x:update"><photo>e45cb3f6fd428966f82f00da47b1abe03439d882</photo></x></presence> <presence id="Hi04F-4" to="dima@jabber-server.de" from="dima@jabber-server.de/1276789248947"><priority>0</priority><x xmlns="vcard-temp:x:update"><photo></photo></x></presence> <iq id="Hi04F-7" to="dima@jabber-server.de/1276789248947" type="get" from="dima@jabber-server.de/1276789248947"><vCard xmlns="vcard-temp"/> </iq> <iq id="Hi04F-6" to="dima@jabber-server.de/1276789248947" type="error" from="jabber-server.de\20support@jabber-server.de/d3dc03d9"><vCard xmlns="vcard-temp"/> <error type="cancel" code="501"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq> ******************************************************************************** And here is user sandra: <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="jabber-server.de" id="597110ca" xml:lang="en" version="1.0"> <stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>JIVE-SHAREDSECRET</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms></stream:features> <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="jabber-server.de" id="597110ca" xml:lang="en" version="1.0"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>JIVE-SHAREDSECRET</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="http://jabber.org/features/iq-auth"/><register xmlns="http://jabber.org/features/iq-register"/></stream:features> <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/> <?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="jabber-server.de" id="597110ca" xml:lang="en" version="1.0"><stream:features><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features> <iq type="result" id="0er0j-0" to="jabber-server.de/597110ca"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>sandra@jabber-server.de/1276789229134</jid></bind></iq> <iq type="result" id="0er0j-1" to="sandra@jabber-server.de/1276789229134"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></iq> <iq type="result" id="0er0j-2" to="sandra@jabber-server.de/1276789229134"><query xmlns="jabber:iq:roster"><item jid="mister\20t@jabber-server.de" name="Mister T" ask="subscribe" subscription="none"><group>Friends</group></item><item jid="dima@jabber-server.de" subscription="from"/><item jid="spiderman@jabber-server.de" subscription="from"/><item jid="jabber-server.de\20support@jabber-server.de" name="Jabber-Server.de Support" subscription="to"><group>Jabber-Server.de Support</group></item><item jid="john@jabber-server.de" name="John" subscription="both"><group>Friends</group></item><item jid="desyadmin@jabber-server.de" name="desyadmin" subscription="both"><group>Friends</group></item></query></iq> <presence from="basics123@jabber-server.de" to="sandra@jabber-server.de" type="subscribe"><x xmlns="vcard-temp:x:update"><photo></photo></x></presence> <presence from="jabber-server.de\20support@jabber-server.de/d3dc03d9" to="sandra@jabber-server.de/1276789229134"><priority>1</priority><c xmlns="http://jabber.org/protocol/caps" node="http://pidgin.im/" hash="sha-1" ver="I22W7CegORwdbnu0ZiQwGpxr0Go="/><x xmlns="vcard-temp:x:update"><photo>e45cb3f6fd428966f82f00da47b1abe03439d882</photo></x></presence> <presence id="0er0j-4" to="sandra@jabber-server.de" from="sandra@jabber-server.de/1276789229134"><priority>0</priority><x xmlns="vcard-temp:x:update"><photo></photo></x></presence> <iq id="0er0j-5" to="sandra@jabber-server.de/1276789229134" type="error" from="jabber-server.de\20support@jabber-server.de/d3dc03d9"><vCard xmlns="vcard-temp"/> <error type="cancel" code="501"><feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq> <iq type="result" id="0er0j-6" from="basics123@jabber-server.de" to="sandra@jabber-server.de/1276789229134"><vCard xmlns="vcard-temp" version="2.0" prodid="-//HandGen//NONSGML vGen v1.0//EN"></vCard></iq> <iq id="0er0j-7" to="sandra@jabber-server.de/1276789229134" type="get" from="sandra@jabber-server.de/1276789229134"><vCard xmlns="vcard-temp"/> </iq> <iq id="Hi04F-5" to="sandra@jabber-server.de/1276789229134" type="get" from="dima@jabber-server.de/1276789248947"><vCard xmlns="vcard-temp"/> </iq> Cheers, Eugen (In reply to comment #2) > (In reply to comment #1) <stuff deleted> > > Do you have the means to try this out with some other service/server? If so do > > you see the same thing? > I tried this out with a different server and indeed it behaves different. Now > user A and B go get all the information, but when I log in a third user C the > odd behavior starts. Sometimes user B doesn't get all the information, > sometimes user A. This is unfortunately not a good sign, as it probably means the server's behavior is somehow not consistent (and probably not as specified by XMPP spec...although I don't have the spec in front of me right now). When I can, I will try out your logins/accounts and see if I can reproduce. You are using a custom client, are you not? Could you make that client code available on this bug also so I can run/debug it? Thanks. Another question Eugen: Are you running these tests with the patch from bug 316071? Or are these tests without that patch? Also: what version of OpenFire is the server running? One thing I've noticed from trying out your server and the two accounts (sandra and dima)...they don't seem to have each other on their rosters...and this could account for the strange inconsistencies you seem to be seeing in the presence handling...as I'm not sure how/what XMPP defines for presence sending/receiving when the participants are not on each other's rosters (I don't know if xmpp specifies the appropriate behavior, as various servers probably treat it differently based upon how public they are). In any event, you might try adding dima to sandras roster, and vice versa. Also, if you could make your client source available I can and will see if I can reproduce using your client. FWIW, I can successfully run the XMPP-based remote services test code with your accounts and server. Created attachment 172273 [details]
Two bundles that connect to an XMPP server using ECF
Hi Scott, here are my bundles. org.remotercp.serviceprovider has a server.properties file where username and pasword can be changed. org.remotercp.connection does all the ECF stuff.
A few more words why the XMPP presence is so important for me. As I understand using ECF for distributed OSGi I need to publish a service to a specific user group = targetIDs:
public synchronized void registerRemoteService(String serviceName,
Object impl, ID[] targetIDs) {
Dictionary<String, ID[]> props = new Hashtable<String, ID[]>();
if (targetIDs == null) {
targetIDs = this.targetIDs.toArray(new XMPPID[0]);
}
props.put(Constants.SERVICE_REGISTRATION_TARGETS, targetIDs);
// register ECF remote service
getRemoteServiceContainerAdapter().registerRemoteService(
new String[] { serviceName }, impl, props);
}
But this user group might change over time as user connect and disconnect. So each time a new user connects I need to publish my services to this new user in order that he will be able to use remote services. Did I get it right?
Regards,
Eugen
(In reply to comment #7) > Created an attachment (id=172273) [details] > Two bundles that connect to an XMPP server using ECF > > Hi Scott, here are my bundles. org.remotercp.serviceprovider has a > server.properties file where username and pasword can be changed. > org.remotercp.connection does all the ECF stuff. > > A few more words why the XMPP presence is so important for me. As I understand > using ECF for distributed OSGi I need to publish a service to a specific user > group = targetIDs: > > public synchronized void registerRemoteService(String serviceName, > Object impl, ID[] targetIDs) { > > Dictionary<String, ID[]> props = new Hashtable<String, ID[]>(); > if (targetIDs == null) { > targetIDs = this.targetIDs.toArray(new XMPPID[0]); > } > props.put(Constants.SERVICE_REGISTRATION_TARGETS, targetIDs); > > // register ECF remote service > getRemoteServiceContainerAdapter().registerRemoteService( > new String[] { serviceName }, impl, props); > } In any event, you might try adding dima to sandras roster, and vice versa. > > But this user group might change over time as user connect and disconnect. So > each time a new user connects I need to publish my services to this new user in > order that he will be able to use remote services. Did I get it right? > > Regards, > Eugen > Are you running these tests with the patch from bug 316071? I guess yes because I've checked out the ECF code and update it every day. >In any event, you might try adding dima to sandras roster, and vice versa. How can I do that? When I log in e.g. Dima he doesn't know anything about sandra and vice versa. So how am I supposed to add them to a roster? >Also: what version of OpenFire is the server running? I don't have this information, sorry. (In reply to comment #7) > Created an attachment (id=172273) [details] > Two bundles that connect to an XMPP server using ECF > > Hi Scott, here are my bundles. org.remotercp.serviceprovider has a > server.properties file where username and pasword can be changed. > org.remotercp.connection does all the ECF stuff. > > A few more words why the XMPP presence is so important for me. As I understand > using ECF for distributed OSGi I need to publish a service to a specific user > group = targetIDs: > > public synchronized void registerRemoteService(String serviceName, > Object impl, ID[] targetIDs) { > > Dictionary<String, ID[]> props = new Hashtable<String, ID[]>(); > if (targetIDs == null) { > targetIDs = this.targetIDs.toArray(new XMPPID[0]); > } > props.put(Constants.SERVICE_REGISTRATION_TARGETS, targetIDs); > > // register ECF remote service > getRemoteServiceContainerAdapter().registerRemoteService( > new String[] { serviceName }, impl, props); > } > > But this user group might change over time as user connect and disconnect. So > each time a new user connects I need to publish my services to this new user in > order that he will be able to use remote services. Did I get it right? No, I don't think so. Since the targetIds array is of length 0, the registration message will not be sent to anyone on registration. (In reply to comment #8) <stuff deleted> > > Are you running these tests with the patch from bug > 316071? > > I guess yes because I've checked out the ECF code and update it every day. The patch on that bug has not yet been applied to HEAD...as it first has to be verified and tested. So it sounds as if you are not using this patch for the moment. > > >In any event, you might try adding dima to sandras roster, and vice versa. > How can I do that? When I log in e.g. Dima he doesn't know anything about > sandra and vice versa. So how am I supposed to add them to a roster? Well, for testing I would suggest that you just use some other client and request adding to the roster on both ends (i.e. both users). It may be possible to also add to the user's rosters on the server, but that depends upon the xmpp server software, and I'm not sure if OpenFire supports this. The ECF API for doing this is org.eclipse.ecf.presence.roster.IRosterSubscriptionSender (and the IRosterListener on the receiving end), but like I said above...I would suggest using some other xmpp client and setting up the rosters for these two users manually (i.e. using the client's user interface). > > But this user group might change over time as user connect and disconnect. So
> > each time a new user connects I need to publish my services to this new user in
> > order that he will be able to use remote services. Did I get it right?
>
> No, I don't think so. Since the targetIds array is of length 0, the
> registration message will not be sent to anyone on registration.
Now it's getting difficult for me now to understand how ECF works. I always thought that if I provide an empty array clients wont't be able to publish their services to specific receivers and due to that receivers won't be able to use these services. Now if I got you right it's not necessary to provide targetIDs, it will also work with an empty array?
If this is true why does the method require targetIDs?
public synchronized void registerRemoteService(String serviceName,
Object impl, ID[] targetIDs)
Regards,
Eugen
(In reply to comment #11) > I always thought that if I provide an empty array clients wont't be able to publish > their services to specific receivers and due to that receivers won't be able to > use these services. I just tried this out and registered a remote service providing an empty list for targetIDs. But when I tried on the other side to retrieve these services I always get an empty result list. Regards, Eugen Maybe I still don't understand how ECF works. Say I have three users:
User A
User B
user C
Each user provides a service and each user should be able to use a service provided by others.
User A --> should be able to retrieve and use services provided by User B and C
User B --> should be able to retrieve and use services provided by User A and C
User C --> should be able to retrieve and use services provided by User A and B
Which parameters do I have to provide within the ECF method:
public interface IRemoteServiceContainerAdapter{
public IRemoteServiceRegistration registerRemoteService(String[] clazzes, Object service, Dictionary properties);
And which parameters do I have to provide within the ECF method:
public interface IRemoteServiceContainerAdapter
public IRemoteServiceReference[] getRemoteServiceReferences(ID[] idFilter, String clazz, String filter)
Regards,
Eugen
(In reply to comment #12) > (In reply to comment #11) > > I always thought that if I provide an empty array clients wont't be able to publish > > their services to specific receivers and due to that receivers won't be able to > > use these services. > > I just tried this out and registered a remote service providing an empty list > for targetIDs. But when I tried on the other side to retrieve these services I > always get an empty result list. Right. That's because the targetIDs list was empty, and no registrations were sent out upon the registerRemoteService call. As I mentioned before, the registerRemoteService call for the XMPP provider is unusual relative to other remote service providers...precisely because there is no clear set of targetIDs to send the add registration to upon remote service registration. This makes it necessary to specify the targetIDs (as the service property Constants.SERVICE_REGISTRATION_TARGETS). (In reply to comment #13) > Maybe I still don't understand how ECF works. Say I have three users: > User A > User B > user C > > Each user provides a service and each user should be able to use a service > provided by others. > User A --> should be able to retrieve and use services provided by User B and C > User B --> should be able to retrieve and use services provided by User A and C > User C --> should be able to retrieve and use services provided by User A and B > > Which parameters do I have to provide within the ECF method: > public interface IRemoteServiceContainerAdapter{ > > public IRemoteServiceRegistration registerRemoteService(String[] clazzes, > Object service, Dictionary properties); > > And which parameters do I have to provide within the ECF method: > public interface IRemoteServiceContainerAdapter > > public IRemoteServiceReference[] getRemoteServiceReferences(ID[] idFilter, > String clazz, String filter) So for User A to make available a remote service to users B and C: properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { BID, CID }); B.registerRemoteService(classes, service, properties); For User B to make available a remote service to users A and C properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { AID, CID }); B.registerRemoteService(classes, service, properties); For User C to make available a remote service to users A and B: properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { AID, BID }); B.registerRemoteService(classes, service, properties); On the lookup end...to get references for remote service exposed by A: B.getRemoteServiceReferences(new ID[] { AID }, class, filter); C.getRemoteServiceReferences(new ID[] { AID }, class, filter); Or on the lookup end...to get references for remote service exposed by A *or* C (on B for example): B.getRemoteServiceReferences(new ID[] { AID, CID }, class, filter); etc. (In reply to comment #15) <stuff deleted> > So for User A to make available a remote service to users B and C: > > properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { BID, CID }); > B.registerRemoteService(classes, service, properties); Correction, this should be: properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { BID, CID }); A.registerRemoteService(classes, service, properties); > > For User B to make available a remote service to users A and C > > properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { AID, CID }); > B.registerRemoteService(classes, service, properties); > > For User C to make available a remote service to users A and B: > > properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { AID, BID }); > B.registerRemoteService(classes, service, properties); Should be properties.put(Constants.SERVICE_REGISTRATION_TARGETS,new ID[] { AID, BID }); C.registerRemoteService(classes, service, properties); > > > On the lookup end...to get references for remote service exposed by A: > > B.getRemoteServiceReferences(new ID[] { AID }, class, filter); > > C.getRemoteServiceReferences(new ID[] { AID }, class, filter); > > Or on the lookup end...to get references for remote service exposed by A *or* C > (on B for example): > > B.getRemoteServiceReferences(new ID[] { AID, CID }, class, filter); > > etc. (In reply to comment #16) >The patch on that bug has not yet been applied to HEAD...as it first has to be >verified and tested. So it sounds as if you are not using this patch for the >moment. Hi Scott, I'm still wrestling with this problem. What I've done so far was to test the presence ability with open source clients like Sparks for Mac OS. Using this client everything seems to work fine. I can connect and disconnect with different users and they appear and disappear properly. So it seems to be an ECF and not an XMPP problem. So before I start to debug ECF where can I get the patch you've mentioned above? Regards, Eugen (In reply to comment #17) > (In reply to comment #16) > >The patch on that bug has not yet been applied to HEAD...as it first has to be > >verified and tested. So it sounds as if you are not using this patch for the > >moment. > > Hi Scott, I'm still wrestling with this problem. What I've done so far was to > test the presence ability with open source clients like Sparks for Mac OS. > Using this client everything seems to work fine. I can connect and disconnect > with different users and they appear and disappear properly. So it seems to be > an ECF and not an XMPP problem. > > So before I start to debug ECF where can I get the patch you've mentioned > above? > > Regards, > Eugen The patch is on bug 316071, but it's since been applied to HEAD. I still suspect your client code has something wrong with it, as I've not observed any issues with roster/presence notifications in the xmpp test code or in the remote service test code (at least after the patch...for gmail accounts). But I have not had a chance to look at your code directly (I'm assuming that's what's in attachment 172273 [details]). I will try to examine this code when I can. Please contact me directly via email to remind me.
> I still suspect your client code has something wrong with it, as I've not
> observed any issues with roster/presence notifications in the xmpp test code or
> in the remote service test code (at least after the patch...for gmail
> accounts). But I have not had a chance to look at your code directly (I'm
> assuming that's what's in attachment 172273 [details]). I will try to examine this code
> when I can. Please contact me directly via email to remind me.
Hi Scott that might be possible but I've reached now a point where I don't understand why my code is not working.
The attached file contains two OSGi bundles:
org. remotercp.connection does all the ECF stuff, connecting, registering and retrieving remote services
org.remotercp.serviceprovider contains a launch configuration for a proper set up and a service.properties file where username and password are provided
I've tried to keep the examples pretty small. I've also created some console output to see what happens if I connect different clients. I expect that each client will be informed about new online clients which doesn't work properly for me. What happens sometimes is that it works for two users but it fails with three of them. Please consider this scenario.
Thanks,
Eugen
(In reply to comment #19) <stuff deleted> > I've tried to keep the examples pretty small. I've also created some console > output to see what happens if I connect different clients. I expect that each > client will be informed about new online clients which doesn't work properly > for me. What happens sometimes is that it works for two users but it fails with > three of them. Please consider this scenario. Could you describe what you are seeing in detail with the three clients case? e.g. the sequence client A (account=foo@bar.com) connects client B (account=foo1@bar1.com) connects A receives B's online presence (and does something?) B receives A's online presence (and does something in response?) client C (account=foo2@bar2.com) connects ? I think this would be helpful so that I can focus in on the 3 client case. Also...you say that *sometimes* the clients all get notified of the others? Is that correct? This makes me think that there is perhaps a race condition (due to the asynchronous aspect of xmpp?)...as this is the only way that I can think of that would result in getting the presence notifications sometimes. So please give as much detail about the sequencing of the observed behavior as you can. Also if I can use the same 3 accounts (along with the code that you've attached) that would good...but I would need pw info (I think I have pw info for the two accounts used previously, but I don't think I know the account info for the 3 account). Thanks. Thanks. (In reply to comment #20) > (In reply to comment #19) > <stuff deleted> > > I've tried to keep the examples pretty small. I've also created some console > > output to see what happens if I connect different clients. I expect that each > > client will be informed about new online clients which doesn't work properly > > for me. What happens sometimes is that it works for two users but it fails with > > three of them. Please consider this scenario. > > Could you describe what you are seeing in detail with the three clients case? > > e.g. the sequence > > client A (account=foo@bar.com) connects > client B (account=foo1@bar1.com) connects > A receives B's online presence (and does something?) > B receives A's online presence (and does something in response?) > client C (account=foo2@bar2.com) connects > ? > > I think this would be helpful so that I can focus in on the 3 client case. > > Also...you say that *sometimes* the clients all get notified of the others? Is > that correct? This makes me think that there is perhaps a race condition (due > to the asynchronous aspect of xmpp?)...as this is the only way that I can think > of that would result in getting the presence notifications sometimes. So > please give as much detail about the sequencing of the observed behavior as you > can. Also if I can use the same 3 accounts (along with the code that you've > attached) that would good...but I would need pw info (I think I have pw info > for the two accounts used previously, but I don't think I know the account info > for the 3 account). Thanks. > > Thanks. Hi Scott, I've been working so far with Eclipse Helios 3.6M6. I just installed the new Helios release and the problem seems to be gone! I tried to connect two, three or even four users and everything seems to work fine. I'm very happy to finally see that. I don't know what changes have been made in Helios+ECF, but my problem seems to be solved! Thank you very much for your support. You've been very patient with me, I appreciate this! Thanks, Eugen (In reply to comment #21) <stuff deleted> > Hi Scott, > > I've been working so far with Eclipse Helios 3.6M6. I just installed the new > Helios release and the problem seems to be gone! I tried to connect two, three > or even four users and everything seems to work fine. I'm very happy to finally > see that. I don't know what changes have been made in Helios+ECF, but my > problem seems to be solved! > > Thank you very much for your support. You've been very patient with me, I > appreciate this! > > Thanks, > Eugen Ok Eugen...I'm happy to hear this. I'm not immediately sure what has changed, but in any event I'm please to hear things are working properly for you. So, I'm going to resolve this bug as worksforme. If you find that the problem described here is not fixed, then please reopen. |
Build Identifier: Eclipse Helios 3.6m6 with ECF latest build I try to connect two clients with an XMPP server. I've registered on both clients an IPresenceListener: getRosterManager().addPresenceListener(new IPresenceListener() { public void handlePresence(ID fromID, IPresence presence) { ... But the odd thing is that handlePresence behaves different than expected: 1. connect user A 2. connect user B User B get's a notification --> user A is online User A does not get a notification that user B has logged in. I tried this out for a long time and it seems sometimes to depend on the sequence I connect clients. But sometimes it doesn't. Reproducible: Always Steps to Reproduce: 1. connect user A 2. connect user B 3. user A shouldn't have got an update presence information for user B