Mailing-List: contact user-help@roller.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@roller.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <471F6CD5.20906@busybuddha.org>
Date: Wed, 24 Oct 2007 09:03:33 -0700
From: Anil Gangolli <anil@busybuddha.org>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: user@roller.apache.org
CC: dev@roller.apache.org
Subject: Re: Ping does this work for anyone
References: <3478d5270710230940j1427268dnbbc037c37e9350c8@mail.gmail.com>
 <471E2832.3050002@busybuddha.org>
In-Reply-To: <471E2832.3050002@busybuddha.org>
Content-Type: multipart/alternative;
 boundary="------------080908020009020800030206"

--------------080908020009020800030206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I looked into this further and have filed 
http://opensource.atlassian.com/projects/roller/browse/ROL-1585

There is a minor  issue with the ping response parsing due to the XML 
rpc client upgrade; the old client used to return HashTable; the new 
client returns a HashMap.  I'm updating to code to expect any Map type. 

However in Steve's specific case, this log message:

DEBUG 2007-10-23 15:54:01,115 WeblogUpdatePinger:sendPing - Ping result is:
PingResult{error=false, message='{message=Ok, flerror=false}'}

(in particular, the embedded '{message=Ok, flerror=false}') indicates 
that the response from the Feedburner ping receiver indicated success.  
So Feedburner should have registered it just fine.  The bug doesn't 
really affect the outcome in this case.

The fix I'll be checking in to the trunk will eliminate the following 
message:

DEBUG 2007-10-23 15:54:01,114 WeblogUpdatePinger:parseResult - Invalid 
ping result of type: java.util.HashMap; proceeding with stand-in 
representative.

and will allow proper detection of error results when they do occur. 

When errors are detected, the automatic ping processing code will retry 
failed pings a configured number of times (default 3) at subsequent ping 
queue processing intervals; with the current parsing issue retrials 
never occur.

--a.


Anil Gangolli wrote:
>
> I think the XML RPC client was updated to a newer rev and it is 
> confusing the Roller's ping response parsing code.  As a result, we 
> aren't able to see the actual ping response value.  It is just 
> assuming that the response was OK; probably it wasn't.
>
> --a.
>
>
> Steve wrote:
>> Hi
>> I am having problems with Ping.   I have registered with 
>> feedburner.com and
>> entered the urls of the feeds I wanted burnt.  I have done this in 
>> the past
>> with Wordpress, and when I post in Wordpress I generally get a 
>> notification
>> from google with in a few minutes of the new blog entry.
>>
>> With roller I get nothing.  If I click the ping button on the page 
>> then I
>> get a message saying the Ping was OK.  The Ping task is picking up 
>> the new
>> posts and the trace below is the debug from the trace  for 
>> feedburner.  Does
>> that look good or bad.  Some parts seem to say it is bad.
>>
>>
>>
>>
>> DEBUG 2007-10-23 15:54:00,888 WebloggerConfig:getProperty - Fetching
>> property [pings.logOnly=false]
>> DEBUG 2007-10-23 15:54:00,889 WebloggerRuntimeConfig:getProperty - 
>> fetched
>> property [site.absoluteurl=http://www.xxxxxxxxxx.com/roller]
>> DEBUG 2007-10-23 15:54:00,890 WeblogUpdatePinger:sendPing - Executing 
>> ping
>> to 'http://ping.feedburner.com' for website '
>> http://www.xxxxxxxxxx.com/roller/maglor' (Maglor)
>> DEBUG 2007-10-23 15:54:01,114 WeblogUpdatePinger:parseResult - 
>> Invalid ping
>> result of type: java.util.HashMap; proceeding with stand-in 
>> representative.
>> DEBUG 2007-10-23 15:54:01,115 WeblogUpdatePinger:sendPing - Ping 
>> result is:
>> PingResult{error=false, message='{message=Ok, flerror=false}'}
>> DEBUG 2007-10-23 15:54:01,115 PingQueueProcessor:processQueueEntry -
>> Processed ping: {42911f63-ab05-4980-8284-8943a16f745e, 2007-10-23 
>> 15:44:33.0,
>> 0}
>> DEBUG 2007-10-23 15:54:01,116 JPAPingQueueManagerImpl:removeQueueEntry -
>> Removing ping queue entry: {42911f63-ab05-4980-8284-8943a16f745e, 
>> 2007-10-23
>> 15:44:33.0, 0}
>>
>>
>>
>>   


--------------080908020009020800030206--