Unable to deploy to AppScale

[GoogleCodeExporter]

What steps will reproduce the problem?
1. After ./runant war finishes running the web.xml file in the WEB-INF folder 
is not capable to be used for uploading to appscale.
2. The test site at http://localhost:8080 does work.
3. Other test apps for appscale are able to upload and run.

What is the expected output?  What do you see instead?

root@appscale-image0:/usr/local/appscale-tools/bin# ./appscale-upload-app 
--file ~/walkaround/build/war/WEB-INF/
We could not find a valid app.yaml or web.xml file in your application.

What browser and browser version are you using?  On what operating system?

root@appscale-image0:/usr/local/appscale-tools/bin# uname -a
Linux appscale-image0 2.6.32-21-server #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC 
2010 x86_64 GNU/Linux

What URL does your browser show when the problem occurs?  Did you compile
walkaround on your machine, or are you using a public instance?
This is a private instance attempt to get around the Read Quota issue.

Please provide any additional information below.

Original issue reported on code.google.com by jg159...@gmail.com on 19 Dec 2011 at 1:53

[GoogleCodeExporter]

I've never worked with AppScale, so I have to guess here.  The error message is 
unfortunately rather unspecific, which leads me to suspect that it's not even 
finding the file.  Have you tried using ~/walkaround/build/war (without the 
/WEB-INF)?

If that doesn't work, can you run appscale-upload-app under strace to see what 
files it's looking for and what it's doing right before it decides to abort?

If it is finding the web.xml file but rejecting it as invalid, you could try 
comparing it to an acceptable web.xml (from an app that works) and commenting 
out different sections to see which section it's unhappy with.

Also, we should simply fix the read quota problem (bug 7) rather than switching 
to AppScale just because of this.

Original comment by oh...@google.com on 19 Dec 2011 at 7:52

[GoogleCodeExporter]

I did try both locations and it still failed.  I did try commenting/adding 
sections from a working sample file; however, it looks like it's needing 
sections that are provided by the guice injection (just my theory).  I will 
have to look up how to run strace and get back to you on that.

I do agree about the bug with the read quota.  We have about 5 people that 
would like to keep the window open to see updates, but we're currently closing 
it and just opening once an hour or so (and still hit the quota).

Thank you for the information,

JG

Original comment by jg159...@gmail.com on 19 Dec 2011 at 8:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

(lets see if this will accept my comment this time...)

I have obtained an strace from  strace -o ~/strace.log appscale-upload-app 
--file  ~/walkaround/build/war/.  I don't know enough to follow the trace 
except to guess that it's linking a temp directory to 
/root/walkaround/build/war and then read the web.xml file (looks like it lstats 
all the files?)

I did try editiy the web.xml file, but I think I guessed wrong on the values to 
put in for servlet-<name, class, mapping> and welcome-file-list.

Any further hints/directions would be appreciated since I'm at the extent of my 
knowledge.

Thanks,

JG

Original comment by jg159...@gmail.com on 20 Dec 2011 at 1:47

Attachments:

• web.xml
• strace.log

[GoogleCodeExporter]

Also I just realized I should have compressed the log file.  Here is a much 
compressed version if you would prefer.

-JG

Original comment by jg159...@gmail.com on 20 Dec 2011 at 1:49

Attachments:

• strace.tar.gz

[GoogleCodeExporter]

Please ask the AppScale list for help.  The fact that appscale-upload-app 
doesn't give us a useful error message here looks like a bug on their side.  
Once they fix that, we can look into what changes are needed in walkaround to 
make it run on AppScale.

Original comment by oh...@google.com on 21 Dec 2011 at 3:59

[GoogleCodeExporter]

You should be able to upload the app with the "./walkabout/build" path after 
you've built it, but the Channel API is currently not supported for Java and 
you'll see "Error: Wave not found or access denied" upon starting a new wave. 
I'll update the mailing list once it is supported or if there is a temporary 
workaround. 

Original comment by nlak...@gmail.com on 22 Dec 2011 at 5:48

[GoogleCodeExporter]

Walkaround should be able to function even without the Channel API; it should 
fall back to polling for edits every few seconds.

What does the server log say when opening a wave, other than "Error: Wave not 
found or access denied"?

Original comment by oh...@google.com on 26 Dec 2011 at 1:24

[GoogleCodeExporter]

This did finally allow me to upload to app-engine (I don't believe i changed 
anything since last trying) but does give the error listed above "Error: Wave 
not found or access denied".  Which server log are you looking for (something 
from app-engine or from within walkaround's logging)?

JG

Original comment by jg159...@gmail.com on 3 Jan 2012 at 6:35

Attachments:

• [wave error.png](https://storage.googleapis.com/google-code-attachments/walkaround/issue-31/comment-9/wave error.png)

[GoogleCodeExporter]

Walkaround's logs, especially the ones generated by the code near 
http://code.google.com/p/walkaround/source/browse/src/com/google/walkaround/wave
/server/servlet/UndercurrentHandler.java#158 , could explain what's going on.

Original comment by oh...@google.com on 3 Jan 2012 at 8:39

[GoogleCodeExporter]

Here is a log snip from my attempt to open that wave.  Java exception at the 
bottom with SlobNotFound.

JG

Original comment by jg159...@gmail.com on 3 Jan 2012 at 9:21

Attachments:

• [appscale log1.txt](https://storage.googleapis.com/google-code-attachments/walkaround/issue-31/comment-11/appscale log1.txt)

[GoogleCodeExporter]

Hmm, maybe this is a bug in AppScale's datastore implementation.  (Or did you 
manually delete some datastore entities?)

The logs say
INFO: SlobId(vQoaOo5WTSeGiG4m) exists and XxMyIDRemovedxX@gmail.com is on the 
ACL
and then later on
Object SlobId(vQoaOo5WTSeGiG4m) not found

Since the ACL entries that the first message refers to are being written in the 
same transaction as the deltas that the second message refers to, finding one 
but not the other should not happen, and I've never seen this in the real 
system.

Do you have a way to check if there are any WaveletDelta entities for 
vQoaOo5WTSeGiG4m in AppScale's datastore?

Which AppScale datastore implementation are you using?  Could it be that it 
doesn't support the below query correctly?
INFO: Run Query Request: app: "gamers-pad",kind: "WaveletDelta",ancestor <app: 
"gamers-pad",path <Element {type: "Wavelet",name: "vQoaOo5WTSeGiG4m"}>>,Filter 
{op: 4,property <name: "__key__",value <ReferenceValue {app: 
"gamers-pad",PathElement {type: "Wavelet",name: "vQoaOo5WTSeGiG4m"},PathElement 
{type: "WaveletDelta",id: 1}}>,multiple: false>},Order {property: 
"__key__",direction: 1},keys_only: false,transaction <handle: 0x39,app: 
"gamers-pad">,compile: true

Original comment by oh...@google.com on 3 Jan 2012 at 11:40

[GoogleCodeExporter]

Marking WontFix since it's not looking like a bug in walkaround, so the fix is 
more likely to be in AppScale.  If it turns out to be a walkaround bug, we can 
reopen it.  We can continue the discussion here even with the bug closed.

Original comment by oh...@google.com on 4 Jan 2012 at 12:31

• Changed state: WontFix

[GoogleCodeExporter]

Thanks, I will try to see if i can force a different DB to be used or if I can 
test that query somehow.

-JG

Original comment by jg159...@gmail.com on 4 Jan 2012 at 3:37

[GoogleCodeExporter]

Thank you very much for your help everyone.  I reran with 
"appscale-run-instances --ips ips.yaml --table mysql" after removing my 
original and now there is no error with creating new waves.  Looks like you're 
right about the SQL not working correctly.  The default is Cassandra.  I 
haven't tried with any other DB backend since I imagine MySQL will have the 
fullest SQL support vs the BigTable variants.

-JG

Original comment by jg159...@gmail.com on 4 Jan 2012 at 2:05