Re: instance or class?
Solved my problem and answered my question as follows: 1. The multi-user problem I was having was unrelated to GWT or Sencha but simply a bug in my program. So neither GWT nor Sencha has a multi-user issue that I am aware of. 2. With respect to the class or instance question, I discovered the following. First GWT doesn't care whether you use a single instance of a class or static methods & variables if you only need a single copy at any given time. However, when using Java generics, you can't variable type static methods or variables. For this reason, you should always use a single instances rather than class methods & variables. If you use the single instance method you leave open the possibility of generalizing your code. Thanks. Blake On Fri, May 10, 2013 at 9:57 AM, Blake McBride wrote: > The way I define the connecting code is as is given in the examples. I > have no thread safety code there. Nevertheless, I am having multi-user > interference issues. Actually, I am using Sencha grid control in the place > where I am having the trouble. I thought this was a generic GWT issue. > Perhaps I am wrong. I'll bring this up with them. > > Thanks. > > Blake > > > > On Fri, May 10, 2013 at 9:37 AM, Jens wrote: > >> >>> Something I am unclear about is the code that connects the frontend to >>> the backend. It seems like GWT duplicates some of the intermediary code >>> that connects the two ends. One in Java that runs on the backend, and >>> another copy that runs on the frontend in JavaScript. For example, the >>> code that defines the data structure that is transmitted between the ends >>> must be available on both ends. This may be where my problem is. I do have >>> instance variables there. Off the cuff, I'm not sure how to protect that. >>> >> >> Using instance variables in objects transferred with GWT-RPC is totally >> thread safe. I would bet its your code that is wrong and not GWT-RPC code, >> otherwise GWT-RPC would be pretty unusable ;-) >> >> You dont have to fear instance variables. Immutable instance variables >> are thread safe by definition and access to mutable instance variables >> needs to be synchronized/atomic to be thread safe. >> >> -- J. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to google-web-toolkit+unsubscr...@googlegroups.com. >> To post to this group, send email to google-web-toolkit@googlegroups.com. >> Visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
The way I define the connecting code is as is given in the examples. I have no thread safety code there. Nevertheless, I am having multi-user interference issues. Actually, I am using Sencha grid control in the place where I am having the trouble. I thought this was a generic GWT issue. Perhaps I am wrong. I'll bring this up with them. Thanks. Blake On Fri, May 10, 2013 at 9:37 AM, Jens wrote: > >> Something I am unclear about is the code that connects the frontend to >> the backend. It seems like GWT duplicates some of the intermediary code >> that connects the two ends. One in Java that runs on the backend, and >> another copy that runs on the frontend in JavaScript. For example, the >> code that defines the data structure that is transmitted between the ends >> must be available on both ends. This may be where my problem is. I do have >> instance variables there. Off the cuff, I'm not sure how to protect that. >> > > Using instance variables in objects transferred with GWT-RPC is totally > thread safe. I would bet its your code that is wrong and not GWT-RPC code, > otherwise GWT-RPC would be pretty unusable ;-) > > You dont have to fear instance variables. Immutable instance variables are > thread safe by definition and access to mutable instance variables needs to > be synchronized/atomic to be thread safe. > > -- J. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
> > > Something I am unclear about is the code that connects the frontend to the > backend. It seems like GWT duplicates some of the intermediary code that > connects the two ends. One in Java that runs on the backend, and another > copy that runs on the frontend in JavaScript. For example, the code that > defines the data structure that is transmitted between the ends must be > available on both ends. This may be where my problem is. I do have > instance variables there. Off the cuff, I'm not sure how to protect that. > Using instance variables in objects transferred with GWT-RPC is totally thread safe. I would bet its your code that is wrong and not GWT-RPC code, otherwise GWT-RPC would be pretty unusable ;-) You dont have to fear instance variables. Immutable instance variables are thread safe by definition and access to mutable instance variables needs to be synchronized/atomic to be thread safe. -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
Interesting. I am familiar with thread issues, and the backend code does not have any static variables either. However, this exchange may have uncovered the problem. Something I am unclear about is the code that connects the frontend to the backend. It seems like GWT duplicates some of the intermediary code that connects the two ends. One in Java that runs on the backend, and another copy that runs on the frontend in JavaScript. For example, the code that defines the data structure that is transmitted between the ends must be available on both ends. This may be where my problem is. I do have instance variables there. Off the cuff, I'm not sure how to protect that. Thanks for the help! Blake On Fri, May 10, 2013 at 7:45 AM, Jens wrote: > If I run it from a single browser (as I do during development) it runs >> fine. It becomes flaky when I try to use it from different browsers and/or >> different machines at the same time. I know about tomcat reusing the same >> backend instances so I am sensitive about that. (I don't know if GlassFish >> does that too.) The backend code for the flaky part has no instance >> variables so reuse should not be a problem. >> >> Due to the responses on this mailing list and my tests, I now think the >> problem is on the backend. One instance runs fine. If I introduce a >> second instance, the second instance runs fine but then the first instance >> messes up randomly. I'll keep looking. >> > > Sounds like a typical thread safety issue. As you said you dont have > instance variables, do you have non final static class variables? If so, > your code probably does not do what you think it should do. Lets assume you > have static int intVariable = 0; somewhere and Thread A sets value to 5 and > later on expects to read a value of 5. Between write and read a second > Thread B could modify the value. This can even happen between two lines of > code. > > Depending on the concrete code you want to use synchronized blocks, > ThreadLocal variables, classes from > http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html > > In case of ThreadLocal variables, make sure to clean them up once the > request is done. Otherwise you probably run into a ThreadLocal memory leaks > and PermGen space issues on redeployment. > > -- J. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
> > If I run it from a single browser (as I do during development) it runs > fine. It becomes flaky when I try to use it from different browsers and/or > different machines at the same time. I know about tomcat reusing the same > backend instances so I am sensitive about that. (I don't know if GlassFish > does that too.) The backend code for the flaky part has no instance > variables so reuse should not be a problem. > > Due to the responses on this mailing list and my tests, I now think the > problem is on the backend. One instance runs fine. If I introduce a > second instance, the second instance runs fine but then the first instance > messes up randomly. I'll keep looking. > Sounds like a typical thread safety issue. As you said you dont have instance variables, do you have non final static class variables? If so, your code probably does not do what you think it should do. Lets assume you have static int intVariable = 0; somewhere and Thread A sets value to 5 and later on expects to read a value of 5. Between write and read a second Thread B could modify the value. This can even happen between two lines of code. Depending on the concrete code you want to use synchronized blocks, ThreadLocal variables, classes from http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html In case of ThreadLocal variables, make sure to clean them up once the request is done. Otherwise you probably run into a ThreadLocal memory leaks and PermGen space issues on redeployment. -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
Greetings, Thanks for the input. Yes, the flakiness is what I am concerned about. The whole project is a no-go until I can figure out the flakiness. First, the backend is running on Linux & GlassFish. The frontend is running on various browsers from various laptops. There is no iOS. I did discover the following however. If I run it from a single browser (as I do during development) it runs fine. It becomes flaky when I try to use it from different browsers and/or different machines at the same time. I know about tomcat reusing the same backend instances so I am sensitive about that. (I don't know if GlassFish does that too.) The backend code for the flaky part has no instance variables so reuse should not be a problem. Due to the responses on this mailing list and my tests, I now think the problem is on the backend. One instance runs fine. If I introduce a second instance, the second instance runs fine but then the first instance messes up randomly. I'll keep looking. Your input is very helpful. Thank you. Blake On Fri, May 10, 2013 at 3:46 AM, Jens wrote: > It shouldn't make a difference if you make everything static or not as > long as your are sure that your app state is the one you want. You would > need to reset your state instead of just throw away an old instance and > create a new one. > > The flakiness you describe sound like iOS issues. Have you tested your app > on iOS 6? If so, iOS 6 caches POST requests if they dont have a no-cache > header and Safari on iOS 6 has some JIT compiler issues which can result in > unexpected JavaScript failures. > > -- J. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
It shouldn't make a difference if you make everything static or not as long as your are sure that your app state is the one you want. You would need to reset your state instead of just throw away an old instance and create a new one. The flakiness you describe sound like iOS issues. Have you tested your app on iOS 6? If so, iOS 6 caches POST requests if they dont have a no-cache header and Safari on iOS 6 has some JIT compiler issues which can result in unexpected JavaScript failures. -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
I thinks it would be better if you included snippets of your code so it's
clearer for anyone wants to help you. You seem to be concerned with
creating and maintaining classes, however, GWT does a lot of clean up for
you, so when you call rootPanel.clear() GWT will detach all of it's widgets
and clear the memory for you AFAIK.
Don't think too much about performance and optomisation at the moment.
On Friday, May 10, 2013 3:17:08 AM UTC+3, Blake wrote:
>
> BeneficiaryPopUpImpl.as
>
> import com.arahant.app.common.BasePopUp;
> import flash.display.DisplayObject;
> import
> com.arahant.app.screen.standard.wizard.benefitWizard.page.simpleX.SimpleXXXScreen;
>
>
>
> if (!mainWindow.contingentBeneficiariesHiddenField.booleanValue) {
> primaryRadioButton.selected = true;
> primaryRadioButton.visible = false;
> contingentRadioButton.visible = false;
> }
>
>
>
> private function get mainWindow():SimpleCoverageScreen
> {
> var parent:DisplayObject = this.parentWindow;
> while (parent is BasePopUp)
> parent = (parent as BasePopUp).parentWindow;
> return parent as SimpleCoverageScreen;
> }
>
>
>
>
> Sorry, that got accidentally sent before it was done. I continue...
>
>
> I have a GWT web app that has several screens. Each screen is
> represented by its own Java class. Each screen starts with the
> following logic:
>
> RootPanel rootPanel = RootPanel.get();
> rootPanel.clear();
>
> I then add the stuff I want to appear on the new screen to rootPanel
> (since each screen doesn't share content with the prior screen).
>
> The first screen (class) is an instance object because that is the way
> GWT spawns it (probably for good reason to support other models). For
> my remaining screens I just use class methods and class variables
> instead of creating an instance. I do this for two reasons. The main
> reason is that I don't have to keep track of which instance when I do
> things with the screen. I would only have one copy of the screen.
>
> I presume that if I opened the same app in another browser tab it
> would be entirely unrelated to the first tab. It would be like
> starting up two copies of the same program. One has nothing to do
> with the other. And, of course, one machine would have utterly
> nothing to do with the other.
>
> This all makes sense in theory and seems to work fine while debugging
> under eclipse. However, when I started it up under glassfish in a
> production environment, my app is flaky. Sometimes I enter data,
> click a button, and nothing happens. Other times a new screen is run
> and no data (from the server) shows up. When I retry it it works. I
> don't know what is causing this but I thought perhaps my unorthodox way
> of switching screens might be the problem.
>
> So, I have two issues. The first issue is whether I can do things with
> classes and resetting the root each time or not. The second is - what
> is causing the flakiness when operating in a production environment?
>
> Any pointers would really be appreciated.
>
> Thanks.
>
> Blake McBride
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: instance or class?
Yet again I mess up the email. Not my day... The email is correct from the sentence that starts with "Sorry". On Thu, May 9, 2013 at 7:17 PM, Blake McBride wrote: > > > > Sorry, that got accidentally sent before it was done. I continue... > > > I have a GWT web app that has several screens. Each screen is > represented by its own Java class. Each screen starts with the > following logic: > > RootPanel rootPanel = RootPanel.get(); > rootPanel.clear(); > > I then add the stuff I want to appear on the new screen to rootPanel > (since each screen doesn't share content with the prior screen). > > The first screen (class) is an instance object because that is the way > GWT spawns it (probably for good reason to support other models). For > my remaining screens I just use class methods and class variables > instead of creating an instance. I do this for two reasons. The main > reason is that I don't have to keep track of which instance when I do > things with the screen. I would only have one copy of the screen. > > I presume that if I opened the same app in another browser tab it > would be entirely unrelated to the first tab. It would be like > starting up two copies of the same program. One has nothing to do > with the other. And, of course, one machine would have utterly > nothing to do with the other. > > This all makes sense in theory and seems to work fine while debugging > under eclipse. However, when I started it up under glassfish in a > production environment, my app is flaky. Sometimes I enter data, > click a button, and nothing happens. Other times a new screen is run > and no data (from the server) shows up. When I retry it it works. I > don't know what is causing this but I thought perhaps my unorthodox way > of switching screens might be the problem. > > So, I have two issues. The first issue is whether I can do things with > classes and resetting the root each time or not. The second is - what > is causing the flakiness when operating in a production environment? > > Any pointers would really be appreciated. > > Thanks. > > Blake McBride > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
instance or class?
BeneficiaryPopUpImpl.as
import com.arahant.app.common.BasePopUp;
import flash.display.DisplayObject;
import
com.arahant.app.screen.standard.wizard.benefitWizard.page.simpleX.SimpleXXXScreen;
if (!mainWindow.contingentBeneficiariesHiddenField.booleanValue) {
primaryRadioButton.selected = true;
primaryRadioButton.visible = false;
contingentRadioButton.visible = false;
}
private function get mainWindow():SimpleCoverageScreen
{
var parent:DisplayObject = this.parentWindow;
while (parent is BasePopUp)
parent = (parent as BasePopUp).parentWindow;
return parent as SimpleCoverageScreen;
}
Sorry, that got accidentally sent before it was done. I continue...
I have a GWT web app that has several screens. Each screen is
represented by its own Java class. Each screen starts with the
following logic:
RootPanel rootPanel = RootPanel.get();
rootPanel.clear();
I then add the stuff I want to appear on the new screen to rootPanel
(since each screen doesn't share content with the prior screen).
The first screen (class) is an instance object because that is the way
GWT spawns it (probably for good reason to support other models). For
my remaining screens I just use class methods and class variables
instead of creating an instance. I do this for two reasons. The main
reason is that I don't have to keep track of which instance when I do
things with the screen. I would only have one copy of the screen.
I presume that if I opened the same app in another browser tab it
would be entirely unrelated to the first tab. It would be like
starting up two copies of the same program. One has nothing to do
with the other. And, of course, one machine would have utterly
nothing to do with the other.
This all makes sense in theory and seems to work fine while debugging
under eclipse. However, when I started it up under glassfish in a
production environment, my app is flaky. Sometimes I enter data,
click a button, and nothing happens. Other times a new screen is run
and no data (from the server) shows up. When I retry it it works. I
don't know what is causing this but I thought perhaps my unorthodox way
of switching screens might be the problem.
So, I have two issues. The first issue is whether I can do things with
classes and resetting the root each time or not. The second is - what
is causing the flakiness when operating in a production environment?
Any pointers would really be appreciated.
Thanks.
Blake McBride
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
