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 +
Select with zone failing intermittently
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.
