You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jim Pinkham <pi...@gmail.com> on 2011/06/03 17:00:04 UTC
Internal Error shows up in Google Cache
I mentioned a few weeks ago I had some page locking issues.
I turned on logging and overrode the PageAccessSynchronizer to log and
swallow the page lock exception (it still has the timeout wait, so
it's not totally disabled), but of course it hasn't happened since, so
I still haven't found the root cause other than some heavier usage
(1500 page loads/day is busy for me - go ahead, laugh ;)
... but now I just noticed my search results in Google are showing
these Internal Error page in search results!
Yikes - Bad news!
So, my band-aid fix is this:
protected final class MyInternalErrorPage extends InternalErrorPage {
private static final long serialVersionUID = 1L;
@Override
public void renderHead(IHeaderResponse response) {
response.renderString("<META NAME=\"ROBOTS\" CONTENT=\"NONE\" />");
}
}
and in my application init():
getApplicationSettings().setInternalErrorPage(MyInternalErrorPage.class);
I'm thinking this might be a good default for this page?
Of course we don't want internal errors in the first place, but if
they do happen (to a robot), no reason to literally advertise the
fact, right? Seems like a drag on the brand name to some degree..
On a side note, does anyone know how to tell google to get rid of a
cached search result like this, or am I stuck waiting for the next
robot to come along?
To see what I mean, google for "Together Auction" (2nd result, crawled
May 21, still here June 3):
Catalog - Internal Error
Internal error. Return to home page.
togetherauction.com/firstuu/catalog - Cached
OK, back to the page locking issues - the only unusual thing I'm doing
is that I have my app deployed at my domain root with suffixes for
each of my clients so they each appear to have their own version of
the web app served from a common ROOT.war. So my URLs are like this:
mydonamin.com/clientname/restOfURL. This is done via a
ClientFirstRootRequestMapper extends AbstractComponentMapper
(source if anyone is interested: http://pastebin.com/Zxp561JK )
For some reason, this was working great in 1.5 M3 but since I've
upgraded to RC3, I'm seeing ;jsessionid= on all my URLs now - not sure
if that is related.
I mention the RequestMapper because I wonder if this might result in
two different clients using same page class with instance keys that
might not be unique and thus have locking conflict from that ?
Thanks for any insights any of you wiser wicket ones might have to share.
-- Jim.
TogetherAuction.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Internal Error shows up in Google Cache
Posted by Martin Grigorov <mg...@apache.org>.
For the synchronization issue see WICKET-3740.
jsessionid in resource urls (.css, .js, ...) is removed in current trunk
About the meta for robots I think it is a good addition to the newly
introduced (today) AbstractErrorPage from which all error pages should
extend.
Please file a RFE.
On Fri, Jun 3, 2011 at 6:00 PM, Jim Pinkham <pi...@gmail.com> wrote:
> I mentioned a few weeks ago I had some page locking issues.
>
> I turned on logging and overrode the PageAccessSynchronizer to log and
> swallow the page lock exception (it still has the timeout wait, so
> it's not totally disabled), but of course it hasn't happened since, so
> I still haven't found the root cause other than some heavier usage
> (1500 page loads/day is busy for me - go ahead, laugh ;)
>
> ... but now I just noticed my search results in Google are showing
> these Internal Error page in search results!
>
> Yikes - Bad news!
>
> So, my band-aid fix is this:
>
> protected final class MyInternalErrorPage extends InternalErrorPage {
> private static final long serialVersionUID = 1L;
>
> @Override
> public void renderHead(IHeaderResponse response) {
> response.renderString("<META NAME=\"ROBOTS\" CONTENT=\"NONE\" />");
> }
> }
>
> and in my application init():
> getApplicationSettings().setInternalErrorPage(MyInternalErrorPage.class);
>
> I'm thinking this might be a good default for this page?
>
> Of course we don't want internal errors in the first place, but if
> they do happen (to a robot), no reason to literally advertise the
> fact, right? Seems like a drag on the brand name to some degree..
>
> On a side note, does anyone know how to tell google to get rid of a
> cached search result like this, or am I stuck waiting for the next
> robot to come along?
>
> To see what I mean, google for "Together Auction" (2nd result, crawled
> May 21, still here June 3):
>
> Catalog - Internal Error
>
> Internal error. Return to home page.
> togetherauction.com/firstuu/catalog - Cached
>
>
> OK, back to the page locking issues - the only unusual thing I'm doing
> is that I have my app deployed at my domain root with suffixes for
> each of my clients so they each appear to have their own version of
> the web app served from a common ROOT.war. So my URLs are like this:
>
> mydonamin.com/clientname/restOfURL. This is done via a
> ClientFirstRootRequestMapper extends AbstractComponentMapper
> (source if anyone is interested: http://pastebin.com/Zxp561JK )
>
> For some reason, this was working great in 1.5 M3 but since I've
> upgraded to RC3, I'm seeing ;jsessionid= on all my URLs now - not sure
> if that is related.
>
> I mention the RequestMapper because I wonder if this might result in
> two different clients using same page class with instance keys that
> might not be unique and thus have locking conflict from that ?
>
> Thanks for any insights any of you wiser wicket ones might have to share.
>
> -- Jim.
>
> TogetherAuction.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org