Yes I know it. I have to fill the response end return from the doGet (req,
resp) method.
I'm very sad because of the 1hour of wasted CPU time. It is the very basic
functionality, but it would consume so much...
I have to investigate both the channel API and the XMPP before I choose the
solution.
Will see if it would be possible to write my own not javascript library to
use the channel API and how much time it will take.
I guess I would like to avoid the XMPP because my modem processor is quite
weak..... have to make some investigation if it handles the requirements.
On Sun, Jan 30, 2011 at 7:30 PM, Stephen Johnson <onepagewo...@gmail.com>wrote:
> If where you have specified log.info("do your stuff here") you intend to
> send data back to the client and then loop again and wait for more data I
> think you are going to be disappointed. I don't believe any data will be
> sent back to the client until your servlet completes. So you'll have to
> re-establish a connection every time data gets sent back down.
>
> On Sun, Jan 30, 2011 at 11:20 AM, Artur Downar <
> artur.dow...@googlemail.com> wrote:
>
>> Yes, you are right.
>> It takes 400-600ms so it costs about an hour of the cpu time per 24hours.
>> It is acceptable.
>>
>>
>> I DO it following way:
>>
>> Map<Object, ToModemInfoEntity> entity;
>>
>>
>> try {
>> for (int i=0; i<100; i++) {
>> entity = ofy.get(ToModemInfoEntity.class);
>> if (entity != null && !entity.isEmpty()) {
>>
>> log.info("got data from db, do my stuff here...");
>> } else {
>> Thread.sleep(100);
>> }
>> }
>> }
>>
>> Can I improove anything else, please ?
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Jan 30, 2011 at 1:36 PM, Didier Durand
>> <durand.did...@gmail.com>wrote:
>>
>>> PS: you should also combine memcache + ds datastore to reduce cpu.
>>>
>>> regards
>>>
>>> didier
>>>
>>> On Jan 30, 1:10 pm, Artur Downar <artur.dow...@googlemail.com> wrote:
>>> > So, you mean polling on the database.
>>> >
>>> > I wrote:
>>> >
>>> > try {
>>> > for (int i=0; i<100; i++) {
>>> > entity = ofy.find(ToModemInfoEntity.class, "whatever");
>>> > if (entity != null) {
>>> > log.info("got data from db, do my stuff here...");
>>> > } else {
>>> > Thread.sleep(100);
>>> > }
>>> > }
>>> > }catch (Throwable th) {
>>> > th.printStackTrace();
>>> > }
>>> >
>>> > It is cpu-time consuming.
>>> > It polls for about 11seconds and it takes about 1500ms of the cpu time.
>>> > It makes more than 2hours of the CPU time per natural day.
>>> >
>>> > I can extend the Time.sleep(period) but it still seems unacceptable due
>>> to
>>> > CPU costs.
>>> >
>>> > On Sun, Jan 30, 2011 at 8:21 AM, Didier Durand <
>>> durand.did...@gmail.com>wrote:
>>> >
>>> > > Sorry,
>>> >
>>> > > hit "send" too quicly
>>> >
>>> > > b) why don't you do something like this
>>> >
>>> > > Side reading data:
>>> > > ==================
>>> >
>>> > > do {
>>> > > read new data from ds;
>>> > > if (new data) {
>>> > > mark data as read in ds
>>> > > do what you need
>>> > > return;
>>> > > } else {
>>> > > Thread.sleep(100)
>>> > > }
>>> > > } until (running time near 30s)
>>> > > if (no new data) {
>>> > > give error message to waiting user
>>> > > }
>>> >
>>> > > Side writing data
>>> > > ==================
>>> >
>>> > > write new data to datastore (with corresponding status showing that
>>> > > it's new and not read yet)
>>> >
>>> > > N.B: the 30s is a hard limit imposed by gae. You've to check for it
>>> > > and end gracefully else your servlet will be killed by GAE.
>>> >
>>> > > regards
>>> >
>>> > > didier
>>> >
>>> > > On Jan 30, 8:15 am, Didier Durand <durand.did...@gmail.com> wrote:
>>> > > > Hi,
>>> >
>>> > > > To answer your questions:
>>> >
>>> > > > a) yes, you can say how long you waits Thread.sleep(millis) where
>>> > > > millis says how many milliseconds you want to wait
>>> >
>>> > > > b) why don't you do something like this
>>> >
>>> > > > do {
>>> > > > read new data from ds;
>>> >
>>> > > > }
>>> >
>>> > > > On Jan 29, 10:38 pm, Stephen Johnson <onepagewo...@gmail.com>
>>> wrote:
>>> >
>>> > > > > At the moment the Channel API is javascript only. There are a lot
>>> of
>>> > > people
>>> > > > > that would like it to be open to other languages for things just
>>> like
>>> > > you
>>> > > > > want to do. You might be able to use something like Rhino to run
>>> the
>>> > > > > javascript in Java but not sure if that will work. You should
>>> take a
>>> > > look at
>>> > > > > XMPP, it's very simple to have the server send instant messages.
>>> I did
>>> > > a
>>> > > > > quick search for XMPP libraries in Java and here is one I found.
>>> I'm
>>> > > sure
>>> > > > > there are many others. Check outhttp://
>>> > > twit88.com/blog/2009/02/17/java-xmpp-client-library/
>>> > > > > On Sat, Jan 29, 2011 at 2:07 PM, Artur Downar
>>> > > > > <artur.dow...@googlemail.com>wrote:
>>> >
>>> > > > > > Thank you.
>>> >
>>> > > > > > I took a brief look on channel API and it seems I it is the
>>> thing I
>>> > > need.
>>> >
>>> > > > > > I have a small question.
>>> >
>>> > > > > > The modem device is a java embedded device and it has no public
>>> IP.
>>> > > There
>>> > > > > > is no javascript on it. Only java.
>>> >
>>> > > > > > Is it enough for GAE channel API to communicate with it ?
>>> >
>>> > > > > > On Sat, Jan 29, 2011 at 9:49 PM, Stephen Johnson <
>>> > > onepagewo...@gmail.com
>>> > > > > > > wrote:
>>> >
>>> > > > > >> Sounds like you need more of a Push style. Checkout the
>>> Channel API
>>> > > or the
>>> > > > > >> XMPP api.
>>> >
>>> > > > > >> On Sat, Jan 29, 2011 at 1:47 PM, Artur Downar <
>>> > > > > >> artur.dow...@googlemail.com> wrote:
>>> >
>>> > > > > >>> The external device polls for data from GAE.
>>> > > > > >>> It is not specified when the data arrives. To describe it
>>> more
>>> > > clearly.
>>> > > > > >>> The device is a GSM modem device that sends an SMS on the
>>> user
>>> > > request.
>>> >
>>> > > > > >>> The user launches a web browser and writes a mobile phone
>>> number.
>>> > > The
>>> > > > > >>> browser sends data to the GAE and the sms should be send
>>> > > immediately
>>> >
>>> > > > > >>> So I cannot specify how long I can wait in Thread.sleep().
>>> >
>>> > > > > >>> You mention about Objectify. I use that library but I'm quite
>>> new
>>> > > to it.
>>> >
>>> > > > > >>> Does it have the mechanism that works like:
>>> >
>>> > > > > >>> process A waits for data until data into database arrives or
>>> > > timeout
>>> > > > > >>> expires
>>> > > > > >>> process B puts the data into database
>>> > > > > >>> process a continues processing the data inserted by process
>>> B
>>> >
>>> > > > > >>> ?
>>> >
>>> > > > > >>> On Sat, Jan 29, 2011 at 3:59 PM, Didier Durand <
>>> > > durand.did...@gmail.com>wrote:
>>> >
>>> > > > > >>>> Hi,
>>> >
>>> > > > > >>>> Forgot: you can use Thread.sleep() to wait (java.lang.Thread
>>> is
>>> > > also
>>> > > > > >>>> part of the JRE)
>>> >
>>> > > > > >>>> regards
>>> >
>>> > > > > >>>> didier
>>> >
>>> > > > > >>>> On Jan 29, 3:35 pm, Didier Durand <durand.did...@gmail.com>
>>> > > wrote:
>>> > > > > >>>> > Hi,
>>> >
>>> > > > > >>>> > LinkedBlokingQueue is part of JRE WhiteList:
>>> > > > > >>>>http://code.google.com/appengine/docs/java/jrewhitelist.html.
>>> So,
>>> > > you
>>> > > > > >>>> > can use it.
>>> >
>>> > > > > >>>> > But, I dont see the need. Why don't you just from on the
>>> > > datastore on
>>> > > > > >>>> > 1 side and read from it on the other. It would be very
>>> simple
>>> > > and rely
>>> > > > > >>>> > on the most basic (i.e solid) mechanism of gae. (I would
>>> > > recommend
>>> > > > > >>>> > Objectify for ds read/ write)
>>> >
>>> > > > > >>>> > As you have network round-trips, the read / write time
>>> will be
>>> > > > > >>>> > negligible even it can seem high compared to an in-memory
>>> > > mechanism
>>> > > > > >>>> > like a Queue.
>>> >
>>> > > > > >>>> > regards
>>> >
>>> > > > > >>>> > didier
>>> >
>>> > > > > >>>> > On Jan 29, 1:51 pm, arturad <artur.dow...@googlemail.com>
>>> > > wrote:
>>> >
>>> > > > > >>>> > > In my application an embedded device (no public IP)
>>> should
>>> > > connect
>>> > > > > >>>> to
>>> > > > > >>>> > > the GAE in order to obtain some data from it. The data
>>> are
>>> > > provided
>>> > > > > >>>> by
>>> > > > > >>>> > > the web browser.
>>> >
>>> > > > > >>>> > > The whole data-passing process looks like:
>>> >
>>> > > > > >>>> > > web
>>> browser ->
>>> > > GAE ->
>>> > > > > >>>> > > embedded standalone device
>>> >
>>> > > > > >>>> > > I developed a servlet the device connects to. It issues
>>> the
>>> > > HTTP
>>> > > > > >>>> GET.
>>> > > > > >>>> > > On the other side the web browser sends data using
>>> standard
>>> > > GWT
>>> > > > > >>>> > > RemoteServiceServlet.
>>> >
>>> > > > > >>>> > > In case there is no data for the device the doGet method
>>> in
>>> > > the
>>> > > > > >>>> > > servlet should stop for some seconds until user enters
>>> data or
>>> > > time
>>> > > > > >>>> > > out expires.
>>> >
>>> > > > > >>>> > > I'm trying to use LinkedBlockingQueue to pass data
>>> between
>>> > > two
>>> > > > > >>>> > > servlets. It does not work unfortunately. Seems like the
>>> GAE
>>> > > > > >>>> launches
>>> > > > > >>>> > > new JVM for concurrent requests... I pushed the
>>> > > LinkedBlockingQueue
>>> > > > > >>>> > > into memcache and get it by name from concurrent
>>> requests.
>>> > > Still
>>> > > > > >>>> does
>>> > > > > >>>> > > not work. Memcache returns NOTnull. But there are no
>>> data in
>>> > > the
>>> > > > > >>>> > > queue.
>>> >
>>> > > > > >>>> > > In order to investigate my issue I've made some tests
>>> with the
>>> > > > > >>>> > > semaphore. Pushed the semaphore to the memcache and made
>>> some
>>> > > > > >>>> > > concurrent operations ... -> does not work -> one
>>> process does
>>> > > not
>>> > > > > >>>> > > release the other...
>>> >
>>> > > > > >>>> > > The problem occurs on GAE only. The whole mechanism
>>> works on
>>> > > the
>>> > > > > >>>> > > development server.
>>> >
>>> > > > > >>>> > > Is there any way to stop/freeze one process (in the
>>> doGet
>>> > > method in
>>> > > > > >>>> > > servlet) and unblock it by another one ?
>>> >
>>> > > > > >>>> > > Or... Is there any other way to solve my problem ?
>>> > > > > >>>> > > Thank you for any suggestions.
>>> > > > > >>>> > > Artur
>>> >
>>> > > > > >>>> --
>>> > > > > >>>> You received this message because you are subscribed to the
>>> Google
>>> > > > > >>>> Groups "Google App Engine for Java" group.
>>> > > > > >>>> To post to this group, send email to
>>> > > > > >>>> google-appengine-java@googlegroups.com.
>>> > > > > >>>> To unsubscribe from this group, send email to
>>> > > > > >>>> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com>
>>> <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> >
>>> > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> <google-appengine-java%252bunsubscr...@googlegroups.com<google-appengine-java%25252bunsubscr...@googlegroups.com>
>>> >
>>> >
>>> > > > > >>>> .
>>> > > > > >>>> For more options, visit this group at
>>> > > > > >>>>http://groups.google.com/group/google-appengine-java?hl=en.
>>> >
>>> > > > > >>> --
>>> > > > > >>> You received this message because you are subscribed to the
>>> Google
>>> > > Groups
>>> > > > > >>> "Google App Engine for Java" group.
>>> > > > > >>> To post to this group, send email to
>>> > > > > >>> google-appengine-java@googlegroups.com.
>>> > > > > >>> To unsubscribe from this group, send email to
>>> > > > > >>> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com>
>>> <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> >
>>> > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> <google-appengine-java%252bunsubscr...@googlegroups.com<google-appengine-java%25252bunsubscr...@googlegroups.com>
>>> >
>>> >
>>> > > > > >>> .
>>> > > > > >>> For more options, visit this group at
>>> > > > > >>>http://groups.google.com/group/google-appengine-java?hl=en.
>>> >
>>> > > > > >> --
>>> > > > > >> You received this message because you are subscribed to the
>>> Google
>>> > > > > >> Groups "Google App Engine for Java" group.
>>> > > > > >> To post to this group, send email to
>>> > > > > >> google-appengine-java@googlegroups.com.
>>> > > > > >> To unsubscribe from this group, send email to
>>> > > > > >> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com>
>>> <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> >
>>> > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> <google-appengine-java%252bunsubscr...@googlegroups.com<google-appengine-java%25252bunsubscr...@googlegroups.com>
>>> >
>>> >
>>> > > > > >> .
>>> > > > > >> For more options, visit this group at
>>> > > > > >>http://groups.google.com/group/google-appengine-java?hl=en.
>>> >
>>> > > > > > --
>>> > > > > > You received this message because you are subscribed to the
>>> Google
>>> > > Groups
>>> > > > > > "Google App Engine for Java" group.
>>> > > > > > To post to this group, send email to
>>> > > > > > google-appengine-java@googlegroups.com.
>>> > > > > > To unsubscribe from this group, send email to
>>> > > > > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com>
>>> <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> >
>>> > > <google-appengine-java%2bunsubscr...@googlegroups.com<google-appengine-java%252bunsubscr...@googlegroups.com>
>>> <google-appengine-java%252bunsubscr...@googlegroups.com<google-appengine-java%25252bunsubscr...@googlegroups.com>
>>> >
>>> >
>>> > > > > > .
>>> > > > > > For more options, visit this group at
>>> > > > > >http://groups.google.com/group/google-appengine-java?hl=en.
>>> >
>>> > > --
>>> > > You received this message because you are subscribed to the Google
>>> >
>>> > ...
>>> >
>>> > read more ยป
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Google App Engine for Java" group.
>>> To post to this group, send email to
>>> google-appengine-java@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-appengine-java?hl=en.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine for Java" group.
>> To post to this group, send email to
>> google-appengine-java@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine for Java" group.
> To post to this group, send email to
> google-appengine-java@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
