(Mostly-)SOLVED: RSSFeed Scanner plugin hanging (forever) at "Connecting"

[FeRDNYC]

It appears that the RSSFeed Scanner plugin has developed a problem accessing some of my feeds (three, all from the same site), and hanging indefinitely on the attempt in a way that blocks it processing the rest of my feeds (two, from two different sites).

First, relevant environment: Vuze 5.7.5.0 running on Fedora Linux 25 x86_64

Code:

Java 1.8.0_121 (64 bit)
Oracle Corporation
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64/jre

SWT v4628, gtk/2.24.31
Linux v4.10.6-200.fc25.x86_64, amd64
V5.7.5.0/4 az2

RSSFeed Scanner plugin version 1.5.3

If I leave the plugin processing the two "good" feeds, everything is fine and it updates normally. However, I had to configure the set of feeds from a third site to Disabled, because attempting to process one of them will lock up the plugin completely, preventing it from processing any of the feeds. Restarting Vuze appears to be the only way to recover when that happens.

A brief walkthrough of what happens:

1. Initial state, RSSFeed Scanner is running normally
   
2. I right-click on a "bad" feed and select "Refresh Feed" (or its reload timer expires, if it's Enabled)
   
3. The "Status/Link" column changes to "Connecting" and gets stuck there
   
4. The "Connecting" status prevents any other feeds (even the "good" ones) from refreshing; if a reload is attempted, the "Status/Link" column changes to "Pending" and gets stuck there
   
5. All feed processing hangs waiting for the "Connecting" status to clear, which it never will (until a Vuze restart)
   

I'm pretty sure that the following message is logged to the Console when the "bad" feed attempts to refresh and gets stuck in "Connecting" mode; it's the only indication I could see in the logs of what's going on, and RSSFeed Scanner reports no logging or status of its own (other than "Connecting").

Code:

[17:34:46.143] {stderr} ........................................................................................................................................
DEBUG::Mon Apr 10 17:34:46 EDT 2017::org.gudy.azureus2.core3.util.DebugLight::printStackTrace::35:
[17:34:46.144] {stderr} java.lang.NullPointerException
[17:34:46.144] {stderr} at org.gudy.azureus2.ui.swt.auth.AuthenticatorWindow$authDialog.<init>;(AuthenticatorWindow.java:410)
[17:34:46.144] {stderr} at org.gudy.azureus2.ui.swt.auth.AuthenticatorWindow$1.runSupport(AuthenticatorWindow.java:357)
[17:34:46.144] {stderr} at org.gudy.azureus2.core3.util.AERunnable.run(AERunnable.java:35)
[17:34:46.145] {stderr} at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
[17:34:46.145] {stderr} at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182)
[17:34:46.145] {stderr} at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4536)
[17:34:46.145] {stderr} at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4154)
[17:34:46.145] {stderr} at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.<init>;(SWTThread.java:308)
[17:34:46.145] {stderr} at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:61)
[17:34:46.145] {stderr} at com.aelitis.azureus.ui.swt.Initializer.<init>;(Initializer.java:159)
[17:34:46.145] {stderr} at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[17:34:46.145] {stderr} at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
[17:34:46.145] {stderr} at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[17:34:46.145] {stderr} at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
[17:34:46.146] {stderr} at org.gudy.azureus2.ui.swt.Main.<init>;(Main.java:111)
[17:34:46.146] {stderr} at org.gudy.azureus2.ui.swt.Main.main(Main.java:334)
[17:34:46.146] {stderr} at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[17:34:46.146] {stderr} at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[17:34:46.146] {stderr} at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[17:34:46.146] {stderr} at java.lang.reflect.Method.invoke(Method.java:498)
[17:34:46.146] {stderr} at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:34)
[17:34:46.146] {stderr} at java.lang.Thread.run(Thread.java:745)
[17:34:46.146] {stderr}

(I inserted a newline before "DEBUG::" to make it wrap better for readability.)
 
So I gather it's attempting to display some sort of authentication window?

The "bad" feeds in question were originally http:// URLs that were being redirected to https:// (the site serving them went HTTPS-everywhere). I edited the config to use the https:// URLs directly, but that didn't make any difference. Of my two "good" feeds, one is HTTP and the other is HTTPS, so I know that the plugin can load HTTPS feeds. It's just failing to, apparently, from this one site.

[parg]

Try 5751_B10 when it appears - thanks!

[FeRDNYC]

I will, thanks!

I was actually going to reply "never mind", as I managed to work around this.

Basically, the site was requesting Authentication, as discovered when I attempted to load a feed URL in Firefox on that machine. (I'd tried it on my local machine, which isn't the one running Vuze, and I didn't get an authentication prompt here because I was already logged in to the site in this browser.)

So, by transferring the session cookies into the plugin configs, I got the feeds un-stuck. Kind of a pain, though, because if Vuze had actually showed me the authentication dialog I could've entered my login credentials and gotten in. Other methods of passing the login info that were recommended in the site forums, such as using https://username:password@site/path.xml URLs, weren't successful with the plugin.

[FeRDNYC]

Try 5751_B10 when it appears - thanks!

 

I beta-updated to 5751_B10 just now, and after turning off the cookie-passing options in the RSSFeed configs and triggering a feed refresh, "Connecting" was immediately followed by an authentication dialog popup. After entering my credentials and checking "Remember Password", the refresh completed and the feed list loaded as expected.

So, yep, fixed in 5751_B10. Thanks!

[parg]

yay!

[FeRDNYC]

So, as a followup to this, I seem to have created a little problem for myself.

Some of the needs-auth sites are working now, but for (at least?) one the connections are failing and I'm getting the following message in the logs at every attempt:

Code:

Authentication for _SERVER_/https://_SERVER_:443// ignored as told not to ask again

It appears that, at some point in my fiddling around, I checked the "Do not ask this again" box in the site's auth dialog. And I can't seem to find any way to undo that, so that I can actually authenticate to the server!

Help?

[FeRDNYC]

It appears that, at some point in my fiddling around, I checked the "Do not ask this again" box in the site's auth dialog. And I can't seem to find any way to undo that, so that I can actually authenticate to the server!
 

I ended up working around this by simply re-enabling the manual cookie passing that I'd previously set up to work around the crashing authentication box. Which works just fine, in terms of getting Vuze pulling results from the RSS feeds in question. But it's still kind of a bummer that I'm not using the built-in authentication capability, now that it's fixed, simply because I can't find a way to UN-disable the authentication dialog for that particular site.

I'm not sure I really understand why that "Do not ask again" box would be there, with no mechanism for reversing the decision, rather than a pattern which uses a "Remember login" checkbox to store the authentication data, but could still pop up the dialog should the stored credentials stop working. Seems an odd decision by Sun/Oracle. (I'm assuming the dialog in question is part of the built-in Java authentication support.)