Thanks a lot for sharing this. I see that I'm only missing the log_path (I remember checking the log file once, it was an sqlite too, really useful if you ask me, but it's not used anywhere yet, wishing it will soon be)
I starred your issue too, "1.1 trigger a code path" not sure what you mean by this, but I also, very rarely, see modifications not live, when you add a blank line and save, it starts showing, very rarely happens On Sunday, March 17, 2013 8:15:32 PM UTC+2, PK wrote: > > As you have probably read 1.7.6 is slated to ship with a new development > server. Last weekend, I finally moved over our infrastructure to the new > development server for python after a few months of on and off efforts. I > was already using HDR & sqlite so no surprises there. Many thanks to Brian > and Sam for fixes and assistance that goes back to December. > > Here are some things that might help your transition and wish I knew on > day one: > > (Unfortunately a productivity related blocker bug see point 5 below still > keeps me on the old server, but all the regression tests now run with the > new server) > > 1. The new server is not command line option for option backwards > compatible. It seems that the Google team took a chance to clean up a > little bit, so expect that you will need to make some changes in your > scripts. Take a look at the new options before you do anything else. > In particular: > 1.1 The host name is now specified using *--host* instead of -a or > --address > 1.2 The admin part now runs as a different server so if you run multiple > configurations on the same machine make sure you use the options * > --admin_host* and *--admin_port* to set them > 1.3 In addition to the datastore data and the blob data, logs now end up > in some structured storage. I did not realize that at the beginning and > running multiple configuration side by side was causing corruptions and > weird crashes. So make sure you set the *--logs_path* to point to where > the logs sqlite file should be located. I am not sure what the default is. > 1.4 dev_appserver.py would not run the tasks by default if you set the * > --enable_tasks=no* but you could manually run them from the admin > console. In the new server this option turns off the tasks completely, not > clear if this is a bug or a new feature. > 1.5 -d does not cut it for debug, you now needs to say *--log_level=debug* > 2. Observed performance is about the same as before both from my > experience and the measurements (it took a while to get there but it seems > that now we are there) > 3. I was using remote_api without specifying both the host and port of my > server before. devappserver2.py is pickier. It took Sam and I several > interaction to nail this issue. > 4. The new server uses different options for log_levels of your code vs > the dev server code (--*dev_appserver_log_level* vs --*log_level*). This > is awesome but might be confusing!! > 5. The new server does not seem to pick up application file modifications. > Please star issue > https://code.google.com/p/appengine-devappserver2-experiment/issues/detail?id=54 > if > you experience the same issue. > > Best, > PK > http://www.gae123.com > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
