well, you do have apache infront of tomcats, which *is* a proxy. i
would write a jmeter script that tried to reproduce this and when you
can run it against tomcat (not going through apache) and see if you
can repro it that way. im guessing its something in your apache config
since you are the only one having this issue.
-igor
On Sun, Nov 7, 2010 at 11:59 PM, Wayne W <waynemailingli...@gmail.com> wrote:
>> the browser. do you have a proxy between the servlet container and the
>> outside? maybe something is injecting a redirect or something weird.
>
> I did wonder if there was weird redirect issue, but after doing a lot
> of reading yesterday it seems the xmlrequest object *should* handle
> redirects fine. However either way we're not doing anything like that.
> We've got a couple of tomcat instances load balanced through apache,
> routed via a hardware firewall and out of the datacenter, so no
> proxies or anything at least I'm aware of.
>
> Its very frustrating.
>
>
>
> On Sun, Nov 7, 2010 at 9:41 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
>> the only way i can see that happenning if the url is no longer
>> processed by wicket's ajax support and so the response just ends up in
>> the browser. do you have a proxy between the servlet container and the
>> outside? maybe something is injecting a redirect or something weird.
>>
>> -igor
>>
>> On Sun, Nov 7, 2010 at 8:26 AM, Wayne W <waynemailingli...@gmail.com> wrote:
>>> thanks Igor,
>>>
>>> I've just spent a few hours stepping though the code and I cannot see
>>> anyway the content type could be set wrong - I see the content type is
>>> set in the final respond(requestCycle) method, so I'm now thinking
>>> this is not a content type issue.
>>>
>>> However we just got another user email with a screen shot showing the
>>> wicket ajax-response in the browser so something is up.
>>>
>>> My javascript knowledge is weak at best so I've not been able to tell
>>> much from the js .
>>>
>>> Any ideas on how we can resolve this or at least get more info?
>>> many thanks
>>>
>>>
>>>
>>>
>>> On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg <igor.vaynb...@gmail.com>
>>> wrote:
>>>> see AjaxRequestTarget class, this is where the response is generated
>>>> on the serverside
>>>>
>>>> wicket-ajax.js is where it is processed on the client side.
>>>>
>>>> -igor
>>>>
>>>> On Sat, Nov 6, 2010 at 2:49 AM, Wayne W <waynemailingli...@gmail.com>
>>>> wrote:
>>>>> Hi Igor,
>>>>>
>>>>> Whats odd is that one guy was getting it on his iPad consistently and
>>>>> when we asked him to try his desktop he's got the same problem on
>>>>> Firefox on Mac. We initially though it might have been a browser
>>>>> issue. We then got another user who got it only once on Chrome on
>>>>> windows - all in the space of 1 day. We're worried that's it happening
>>>>> more often but users are not reporting the issue.
>>>>>
>>>>> Of course we cannot reproduce the issue, but its definitely happening.
>>>>>
>>>>> So you don;t think the shared resource could effect the threads in any
>>>>> way?
>>>>>
>>>>> Where can I start looking in the wicket code to understand where ajax
>>>>> requests are serviced etc? Is there any where/docs I can find to get
>>>>> started at looking at this? - at least to complete more my
>>>>> understanding of how it all works.
>>>>>
>>>>> thanks
>>>>> Wayne
>>>>>
>>>>> On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg <igor.vaynb...@gmail.com>
>>>>> wrote:
>>>>>> it may be a content type issue, but it is still weird because the
>>>>>> response is received by the xml http request object, not the browser
>>>>>> directly. strange indeed.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Fri, Nov 5, 2010 at 7:51 AM, Wayne W <waynemailingli...@gmail.com>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> has anyone had this issue? We're getting emails from our users that
>>>>>>> sometime when clicking on an ajax link the raw wicket ajax response is
>>>>>>> being rendered on the browser - ie the just see all the html source
>>>>>>> code on the page. Its not any particular page.
>>>>>>>
>>>>>>> Anyone seen this or has any ideas?
>>>>>>>
>>>>>>>
>>>>>>> The only thing we have changed recently was adding a non blocking file
>>>>>>> download using a link and a shared resource which could be related due
>>>>>>> to the Content Type.
>>>>>>> In the configureResponse of the shared resource that we set the
>>>>>>> Content Type for that request. Is there any chance that this is
>>>>>>> somehow polluting the other threads requests?
>>>>>>>
>>>>>>> public class DownloadFileResourceReference extends ResourceReference {
>>>>>>> public DownloadFileResourceReference() {
>>>>>>> super(DownloadLink.class, "");
>>>>>>> }
>>>>>>>
>>>>>>> private static final long serialVersionUID = 1L;
>>>>>>>
>>>>>>> public Resource newResource() {
>>>>>>>
>>>>>>> Resource r = new Resource() {
>>>>>>> private static final long serialVersionUID = 1L;
>>>>>>>
>>>>>>> public IResourceStream getResourceStream() {
>>>>>>>
>>>>>>> Long id =
>>>>>>> getParameters().getLong(DownloadLink.DOCID);
>>>>>>> // get file
>>>>>>>
>>>>>>> return new
>>>>>>> FileResourceStream(new File(file.getAbsolutePath()));
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> protected void configureResponse(Response
>>>>>>> response) {
>>>>>>>
>>>>>>> Long id =
>>>>>>> getParameters().getLong(DownloadLink.DOCID);
>>>>>>>
>>>>>>> // get file
>>>>>>>
>>>>>>> ((WebResponse)
>>>>>>> response).setAttachmentHeader(df.getFileName());
>>>>>>>
>>>>>>> String mimeType =
>>>>>>> ResourceHelper.getContentType(df.getFileName());
>>>>>>> if (!StringUtils.isEmpty(mimeType)) {
>>>>>>> ((WebResponse)
>>>>>>> response).setContentType(mimeType);
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> };
>>>>>>> r.setCacheable(false);
>>>>>>> return r;
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
