fixed discovery of remote wave service JIDs

[GoogleCodeExporter]

> What steps will reproduce the problem?
Connect to a wave server running more than one XMPP service.
If the wave server is not the first JID listed, you will be unable to 
connect, because the code in XmppDisco.java is testing them one at a time, 
and waiting forever for responses which do not come.

> What is the expected output? What do you see instead?
There should be disco#info requests and responses for more than just the 
first item.

> What version of the product are you using? On what operating system?
0bf003ae4aae, on Ubuntu Linux

> Please provide any additional information below.
My patch, which I just submitted via the request_codereview tool, fixes this 
issue by causing a disco#info request to be sent for each JID provided by 
the XMPP server in the disco#items response.

I also have added several small tweaks to the shell scripts for 
compatibility with dash, the 'sh' in Ubuntu, and for my own preferences.  
What is most significant, however, are my changes to XmppDisco.java.  You 
may also want to add more testing beyond the changes I have made to 
XmppDiscoTest.java.

I hope this will make new testing easier for people!

-- Kevin Cantu

Original issue reported on code.google.com by kevincantu on 21 Oct 2009 at 4:26

Attachments:

• wave-protocol-kshh-f77326b8f09d.diff

[GoogleCodeExporter]

I have a different fix in my clone (anthonybaxter-federation) that will be 
merged into 
the mainline in a few hours.

Original comment by anthonybaxter@gmail.com on 30 Oct 2009 at 3:56

[GoogleCodeExporter]

Anthony, can you close this issue if it has been fixed?

Original comment by btkalman@gmail.com on 4 Nov 2009 at 2:53

• Changed state: Started

[GoogleCodeExporter]

Original comment by anthonybaxter@gmail.com on 5 Nov 2009 at 6:01

• Changed state: Fixed

[GoogleCodeExporter]

These symptoms reappear with some certificate problems.

As is described here (http://groups.google.com/group/wave-
protocol/browse_thread/thread/dccfcd4a2f9ee224), if you run pubsub and 
conference 
services on Openfire, and do not have certificates for those, this symptom 
reappears.  A 
disco#info is requested for the firsts JID (e.g., conference) and then the 
second JID is 
never queried for disco#info.

Is it possible that the queue for testing every JID, one after the other, is 
something 
of a premature optimization?  I haven't looked at the other code behind this 
current 
failure yet, but will if I have time...

Original comment by kevincantu on 9 Nov 2009 at 2:13

[GoogleCodeExporter]

An alternative to parallel discovery is to add a timeout. If FedOne doesn't get 
a
response to a disco request within some configurable amount of time it should
probably either try again, or give up on that JID.

Original comment by Tad.Glines@gmail.com on 9 Nov 2009 at 10:02

[GoogleCodeExporter]

Oh, I agree.  It is probably reasonable to roll this into whatever fix is done 
for Issue 
58.  http://code.google.com/p/wave-protocol/issues/detail?id=58

Original comment by kevincantu on 11 Nov 2009 at 5:44