Re: Select with zone failing intermittently
Can you see the request hitting the server after the first zone's value is changed? Uli On 24.02.2011 23:43, Bryan Lewis wrote: I've been trying to figure out a weird bug today, and before I lose the night over it I thought I'd ask the list. I'm using the cool new chained select feature. One Select has a zone, and triggers an onValueChanged() method that affects another Select. It works fine on my machine and when most users try it. When the first selection changes the server gets the method call and the zone updates, no problem. We have a few users in a remote office who access the application through a slightly slow connection to a Citrix server. That is, the browser is actually running here (in the same network as the app server) and the user receives only screen updates. Occasionally these users will see that the chained selects don't work at all. I've debugged it a little (kinda difficult since I can't make it happen locally) and the first Select's method call doesn't happen. I don't think it's only a case of slowness -- I waited about ten seconds. Does this ring any bells? I can't see how the Citrix factor or the connection speed would have any effect. The app server and browser are in the same network. Other requests are working fine; the app has been running almost a year. I have a periodic-update ajax request that successfully makes it to the server for the same user. So maybe I'm using the new feature incorrectly. .tml: t:zone t:id=recipientZone update=show br/ t:label for=carrierSelectRecipients/t:label table style=margin-left:124px; tr td t:select t:id=carrierSelect model=carrierModel value=selectedCarrier blankLabel=literal:Select a carrier first zone=recipientZone style=width:180px;/ /td td t:select t:id=recipientSelect model=recipientModel value=selectedRecipient style=width:360px;/ /td /tr /table /t:zone .java: private final SelectModel carrierModel = new AbstractSelectModel() { // Omitting null-returning getOptionGroups() for simplicity public ListOptionModel getOptions() { ListCompany carriers = getModel().getCarriers(); // sorted by name ListOptionModel options = CollFactory.newList(carriers.size()); for (Company carrier : carriers) { options.add(new OptionModelImpl(carrier.getCarrierShortName(), carrier)); } return options; } }; public SelectModel getCarrierModel() { return carrierModel; } public Object onValueChangedFromCarrierSelect(Company carrier) { debug(-- onValueChangedFromCarrierSelect + carrier.getCarrierShortName()); selectedCarrier = carrier; return recipientZone.getBody(); } To be clear: In the real app, the recipientSelect also has a zone parameter to update a third list. I omitted it here because the bug happens before that. The only thing I can see that I'm doing different from the documented example is, my selects are in the same zone. I'll try splitting them up and using a MultiZoneUpdate or some such. Thanks for any ideas. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select with zone failing intermittently
Nope. In the failing cases, the ajax request did not arrive at my AppModule's request filter. That's why the Select's onValueChanged() isn't getting called. I don't think it's a case of Tapestry dropping the request after it gets it. On Fri, Feb 25, 2011 at 6:41 AM, Ulrich Stärk u...@spielviel.de wrote: Can you see the request hitting the server after the first zone's value is changed? Uli On 24.02.2011 23:43, Bryan Lewis wrote: I've been trying to figure out a weird bug today, and before I lose the night over it I thought I'd ask the list. I'm using the cool new chained select feature. One Select has a zone, and triggers an onValueChanged() method that affects another Select. It works fine on my machine and when most users try it. When the first selection changes the server gets the method call and the zone updates, no problem. We have a few users in a remote office who access the application through a slightly slow connection to a Citrix server. That is, the browser is actually running here (in the same network as the app server) and the user receives only screen updates. Occasionally these users will see that the chained selects don't work at all. I've debugged it a little (kinda difficult since I can't make it happen locally) and the first Select's method call doesn't happen. I don't think it's only a case of slowness -- I waited about ten seconds. Does this ring any bells? I can't see how the Citrix factor or the connection speed would have any effect. The app server and browser are in the same network. Other requests are working fine; the app has been running almost a year. I have a periodic-update ajax request that successfully makes it to the server for the same user. So maybe I'm using the new feature incorrectly. .tml: t:zone t:id=recipientZone update=show br/ t:label for=carrierSelectRecipients/t:label table style=margin-left:124px; tr td t:select t:id=carrierSelect model=carrierModel value=selectedCarrier blankLabel=literal:Select a carrier first zone=recipientZone style=width:180px;/ /td td t:select t:id=recipientSelect model=recipientModel value=selectedRecipient style=width:360px;/ /td /tr /table /t:zone .java: private final SelectModel carrierModel = new AbstractSelectModel() { // Omitting null-returning getOptionGroups() for simplicity public ListOptionModel getOptions() { ListCompany carriers = getModel().getCarriers(); // sorted by name ListOptionModel options = CollFactory.newList(carriers.size()); for (Company carrier : carriers) { options.add(new OptionModelImpl(carrier.getCarrierShortName(), carrier)); } return options; } }; public SelectModel getCarrierModel() { return carrierModel; } public Object onValueChangedFromCarrierSelect(Company carrier) { debug(-- onValueChangedFromCarrierSelect + carrier.getCarrierShortName()); selectedCarrier = carrier; return recipientZone.getBody(); } To be clear: In the real app, the recipientSelect also has a zone parameter to update a third list. I omitted it here because the bug happens before that. The only thing I can see that I'm doing different from the documented example is, my selects are in the same zone. I'll try splitting them up and using a MultiZoneUpdate or some such. Thanks for any ideas. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select with zone failing intermittently
To follow up... moving the first select out of the zone didn't help. I didn't see how it would, was grasping at straws. I finally avoided the problem by getting rid of the chained selects. I went back to our older component that does the chaining with simple javascript (stuffing all the possible selection lists into the html which works okay if they're not huge), so there's no ajax request on the first select. The second select does an onchange form submit. Crude and a bit slower but it works. In other words it stumped me. Maybe some day someone else will see this posting and have an insight. On Fri, Feb 25, 2011 at 10:24 AM, Bryan Lewis jbryanle...@gmail.com wrote: Nope. In the failing cases, the ajax request did not arrive at my AppModule's request filter. That's why the Select's onValueChanged() isn't getting called. I don't think it's a case of Tapestry dropping the request after it gets it. On Fri, Feb 25, 2011 at 6:41 AM, Ulrich Stärk u...@spielviel.de wrote: Can you see the request hitting the server after the first zone's value is changed? Uli On 24.02.2011 23:43, Bryan Lewis wrote: I've been trying to figure out a weird bug today, and before I lose the night over it I thought I'd ask the list. I'm using the cool new chained select feature. One Select has a zone, and triggers an onValueChanged() method that affects another Select. It works fine on my machine and when most users try it. When the first selection changes the server gets the method call and the zone updates, no problem. We have a few users in a remote office who access the application through a slightly slow connection to a Citrix server. That is, the browser is actually running here (in the same network as the app server) and the user receives only screen updates. Occasionally these users will see that the chained selects don't work at all. I've debugged it a little (kinda difficult since I can't make it happen locally) and the first Select's method call doesn't happen. I don't think it's only a case of slowness -- I waited about ten seconds. Does this ring any bells? I can't see how the Citrix factor or the connection speed would have any effect. The app server and browser are in the same network. Other requests are working fine; the app has been running almost a year. I have a periodic-update ajax request that successfully makes it to the server for the same user. So maybe I'm using the new feature incorrectly. .tml: t:zone t:id=recipientZone update=show br/ t:label for=carrierSelectRecipients/t:label table style=margin-left:124px; tr td t:select t:id=carrierSelect model=carrierModel value=selectedCarrier blankLabel=literal:Select a carrier first zone=recipientZone style=width:180px;/ /td td t:select t:id=recipientSelect model=recipientModel value=selectedRecipient style=width:360px;/ /td /tr /table /t:zone .java: private final SelectModel carrierModel = new AbstractSelectModel() { // Omitting null-returning getOptionGroups() for simplicity public ListOptionModel getOptions() { ListCompany carriers = getModel().getCarriers(); // sorted by name ListOptionModel options = CollFactory.newList(carriers.size()); for (Company carrier : carriers) { options.add(new OptionModelImpl(carrier.getCarrierShortName(), carrier)); } return options; } }; public SelectModel getCarrierModel() { return carrierModel; } public Object onValueChangedFromCarrierSelect(Company carrier) { debug(-- onValueChangedFromCarrierSelect + carrier.getCarrierShortName()); selectedCarrier = carrier; return recipientZone.getBody(); } To be clear: In the real app, the recipientSelect also has a zone parameter to update a third list. I omitted it here because the bug happens before that. The only thing I can see that I'm doing different from the documented example is, my selects are in the same zone. I'll try splitting them up and using a MultiZoneUpdate or some such. Thanks for any ideas. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Select with zone failing intermittently
I can't say with any certainty this is your problem, but the one time I was having issues with an AJAX request being dumped and never showing up server side there was a race condition. I had it listening to the click event of a submit button, and on slower connections the form submit would beat out the AJAX request to the server. In your case I could see the Periodic update (assuming its on the same page) creating some sort of race condition. Worth considering if so. Here is the link to the thread on this list so you can compare and see if your code is similar: http://tapestry.markmail.org/thread/6nlztv5dlv4pix77 Regards, Rich On 02/25/2011 10:35 AM, Bryan Lewis wrote: To follow up... moving the first select out of the zone didn't help. I didn't see how it would, was grasping at straws. I finally avoided the problem by getting rid of the chained selects. I went back to our older component that does the chaining with simple javascript (stuffing all the possible selection lists into the html which works okay if they're not huge), so there's no ajax request on the first select. The second select does an onchange form submit. Crude and a bit slower but it works. In other words it stumped me. Maybe some day someone else will see this posting and have an insight. On Fri, Feb 25, 2011 at 10:24 AM, Bryan Lewisjbryanle...@gmail.com wrote: Nope. In the failing cases, the ajax request did not arrive at my AppModule's request filter. That's why the Select's onValueChanged() isn't getting called. I don't think it's a case of Tapestry dropping the request after it gets it. On Fri, Feb 25, 2011 at 6:41 AM, Ulrich Stärku...@spielviel.de wrote: Can you see the request hitting the server after the first zone's value is changed? Uli On 24.02.2011 23:43, Bryan Lewis wrote: I've been trying to figure out a weird bug today, and before I lose the night over it I thought I'd ask the list. I'm using the cool new chained select feature. One Select has a zone, and triggers an onValueChanged() method that affects another Select. It works fine on my machine and when most users try it. When the first selection changes the server gets the method call and the zone updates, no problem. We have a few users in a remote office who access the application through a slightly slow connection to a Citrix server. That is, the browser is actually running here (in the same network as the app server) and the user receives only screen updates. Occasionally these users will see that the chained selects don't work at all. I've debugged it a little (kinda difficult since I can't make it happen locally) and the first Select's method call doesn't happen. I don't think it's only a case of slowness -- I waited about ten seconds. Does this ring any bells? I can't see how the Citrix factor or the connection speed would have any effect. The app server and browser are in the same network. Other requests are working fine; the app has been running almost a year. I have a periodic-update ajax request that successfully makes it to the server for the same user. So maybe I'm using the new feature incorrectly. .tml: t:zone t:id=recipientZone update=show br/ t:label for=carrierSelectRecipients/t:label table style=margin-left:124px; tr td t:select t:id=carrierSelect model=carrierModel value=selectedCarrier blankLabel=literal:Select a carrier first zone=recipientZone style=width:180px;/ /td td t:select t:id=recipientSelect model=recipientModel value=selectedRecipient style=width:360px;/ /td /tr /table /t:zone .java: private final SelectModel carrierModel = new AbstractSelectModel() { // Omitting null-returning getOptionGroups() for simplicity public ListOptionModel getOptions() { ListCompany carriers = getModel().getCarriers(); // sorted by name ListOptionModel options = CollFactory.newList(carriers.size()); for (Company carrier : carriers) { options.add(new OptionModelImpl(carrier.getCarrierShortName(), carrier)); } return options; } }; public SelectModel getCarrierModel() { return carrierModel; } public Object onValueChangedFromCarrierSelect(Company carrier) { debug(-- onValueChangedFromCarrierSelect + carrier.getCarrierShortName()); selectedCarrier = carrier; return recipientZone.getBody(); } To be clear: In the real app, the recipientSelect also has a zone parameter to update a third list. I omitted it here because the bug happens before that. The only thing I can
Re: Select with zone failing intermittently
Thanks for the info! I don't think that's the culprit here, although I'll keep in mind that multiple requests might not arrive in the order sent. On Fri, Feb 25, 2011 at 11:04 AM, Rich M rich...@moremagic.com wrote: I can't say with any certainty this is your problem, but the one time I was having issues with an AJAX request being dumped and never showing up server side there was a race condition. I had it listening to the click event of a submit button, and on slower connections the form submit would beat out the AJAX request to the server. In your case I could see the Periodic update (assuming its on the same page) creating some sort of race condition. Worth considering if so. Here is the link to the thread on this list so you can compare and see if your code is similar: http://tapestry.markmail.org/thread/6nlztv5dlv4pix77 Regards, Rich On 02/25/2011 10:35 AM, Bryan Lewis wrote: To follow up... moving the first select out of the zone didn't help. I didn't see how it would, was grasping at straws. I finally avoided the problem by getting rid of the chained selects. I went back to our older component that does the chaining with simple javascript (stuffing all the possible selection lists into the html which works okay if they're not huge), so there's no ajax request on the first select. The second select does an onchange form submit. Crude and a bit slower but it works. In other words it stumped me. Maybe some day someone else will see this posting and have an insight. On Fri, Feb 25, 2011 at 10:24 AM, Bryan Lewisjbryanle...@gmail.com wrote: Nope. In the failing cases, the ajax request did not arrive at my AppModule's request filter. That's why the Select's onValueChanged() isn't getting called. I don't think it's a case of Tapestry dropping the request after it gets it. On Fri, Feb 25, 2011 at 6:41 AM, Ulrich Stärku...@spielviel.de wrote: Can you see the request hitting the server after the first zone's value is changed? Uli On 24.02.2011 23:43, Bryan Lewis wrote: I've been trying to figure out a weird bug today, and before I lose the night over it I thought I'd ask the list. I'm using the cool new chained select feature. One Select has a zone, and triggers an onValueChanged() method that affects another Select. It works fine on my machine and when most users try it. When the first selection changes the server gets the method call and the zone updates, no problem. We have a few users in a remote office who access the application through a slightly slow connection to a Citrix server. That is, the browser is actually running here (in the same network as the app server) and the user receives only screen updates. Occasionally these users will see that the chained selects don't work at all. I've debugged it a little (kinda difficult since I can't make it happen locally) and the first Select's method call doesn't happen. I don't think it's only a case of slowness -- I waited about ten seconds. Does this ring any bells? I can't see how the Citrix factor or the connection speed would have any effect. The app server and browser are in the same network. Other requests are working fine; the app has been running almost a year. I have a periodic-update ajax request that successfully makes it to the server for the same user. So maybe I'm using the new feature incorrectly. .tml: t:zone t:id=recipientZone update=show br/ t:label for=carrierSelectRecipients/t:label table style=margin-left:124px; tr td t:select t:id=carrierSelect model=carrierModel value=selectedCarrier blankLabel=literal:Select a carrier first zone=recipientZone style=width:180px;/ /td td t:select t:id=recipientSelect model=recipientModel value=selectedRecipient style=width:360px;/ /td /tr /table /t:zone .java: private final SelectModel carrierModel = new AbstractSelectModel() { // Omitting null-returning getOptionGroups() for simplicity public ListOptionModel getOptions() { ListCompany carriers = getModel().getCarriers(); // sorted by name ListOptionModel options = CollFactory.newList(carriers.size()); for (Company carrier : carriers) { options.add(new OptionModelImpl(carrier.getCarrierShortName(), carrier)); } return options; } }; public SelectModel getCarrierModel() { return carrierModel; } public Object onValueChangedFromCarrierSelect(Company carrier) { debug(-- onValueChangedFromCarrierSelect +