Since the morning I try to build an android application, in the Builds part it shows only Android Build Error and when I click on ERROR LOG it shows a page not found error. Is there any problem with build server??
This happens for older versions of the plugins that still send to the google cloud. We've tried to track it down but it failed badly and since we're killing off support to these old plugins anyway the right solution is probably to just move forward.
This build still works your error URL is just broken and looks like: https://cloud.codenameone.comhttps//codename-one.appspot.com/getData?...
You can see the actual error by fixing the URL to remove the prefix and add the missing ::
https://codename-one.appspot.com/getData?...
I'm guessing the error is due to downgrading to a free account or something similar. This happens because of the migration process to the new server once you follow these steps this problem should resolve itself.
Also starting this weekend builds sent using the old plugin or an old project will fail. You will need to update the plugin to 4.3 (or 4.0.3 in NetBeans) or newer. This is an important phase in removing App Engine from our build stack and moving to a new system.
If you are experiencing problems with a project do the following:
Right Click the project
Select Codename One → Codename One Settings or Codename One Preferences
Click Basic
Click Update Project Libs in the bottom left side
Related
I have a 2sxc App that was written about 3 years ago and was last modified using 2sxc 9.43.2 LTS on DNN v8+. I restored the old DNN site and got everything working locally. I wanted to import this app in to a modern DNN v9.10+. I chose 2sxc v13.12.1 LTS. I installed that on the new, clean install of DNN 9.10.02 and then upgraded 2sxc on the old DNN v8 site to v13.12.1. Tested the app, still working! I figured if 2sxc was the same on both instances I'd have a pretty good chance of the import/export working.
First I tried exporting the whole app. That fails and I can't find any useful errors logged anywhere. So I switched and decided I would just export the content-types and rebuild the app manually since it only had 3 or 4 views, 3 content-types, and 1 query.
But exporting any of the content-types fails on import. See screen-clip below. I think I understand the error, but I am not clear as to what I need to do to fix this. Both the old site and the new site only have the DNN default, US English. Neither ever had another language added, there doesn't appear to be any differences in the DNN settings for this, I compared them side by side.
So what is the fix? Is there something I can change in 2sxc or the App in the old or new site to get the export/import to align? Can I just add the needed language to the Zone? If yes, where and how do I do that?
Can you explain what the error means, "entity has 1 zone has 0 used-list: 'en-us'"?
If I just need to add 'en-us' in the Zone, what does that mean or how do I do it?
screen clip:
It means that the json which is to be imported does report a language - en-us. I'm not sure why - maybe the source did activate english at some time.
You should be able to get this going by exporting a content type from the target system and comparing the json with the one you want to import, and probably manually patch it.
I have a python27 appengine application. My application generates a 500 error early in the code initialization, and I can inspect the stack trace in the StackDriver debugger in the GCP console.
I've since patched the code, and I've re-deployed under the same service name and version name (i.e. gcloud app deploy --version=SAME). Unfortunately, the old error still comes up, and line numbers in the stack traces reflect the files in the buggy deployment. If I use the code viewer to debug the error, I am however brought to the updated patched code in the online viewer -- and there is a mismatch. It behave as if the app instance is holding on to a previous snapshot of the code.
I'm fuzzy on the freshness and eventual consistency guarantees of GAE. Do I have to wait to get everything to serve the latest deployed version? Can I force it to use the newer code right away?
Things I've tried:
I initially assumed the problem had to do with versioning, i.e. maybe requests being load-balanced between instances with the same version, but each with slightly different code. I'm a bit fuzzy on the actual rules that govern which GAE instance gets chosen for a new request (esp whether GAE tries to reuse previous instances based on a source IP). I'm also fuzzy on whether or not active instances get destroyed right away when different code is redeployed under the same version name.
To take that possibility out of the equation, I tried pushing to a new version name, and then deleting all previous versions (using gcloud app versions list to get the list). But it doesn't help -- I still get stack traces from the old code, despite the source being up to date in the GCP console debugger. Waiting a couple hours doesn't do anything either.
I've tried two things:
disabling and re-enabling the application in GAE->Settings
I'd also noticed that there were some .pyc files uploaded in the snapshot, so I removed those and re-deployed.
I discovered that (1) is a very effective way to stop all running appengine instances. When you deploy a new version of a project, a traffic split is created (i.e. 0% for the old version and 100% for the new), but in my experience old instances might still be running if they've been used recently (despite them being configured to receive 0% of traffic). Toggling kills them all immediately. I unfortunately found that my stale code was still being used after re-enabling.
(2) did the trick. It wasn't obvious that .pyc were being uploaded. I discovered it by looking at GCP->StackDriver->Debug and I saw .pyc files in the tree snapshot.
I had recently updated my .gitignore to ignore locally installed pip runtime dependencies for the project (output of pip install -t lib requirements.txt). I don't want those in git, but they do need to ship as part of my appengine project. I had removed the #!.gitignore special include line from .gcloudignore. However, I forgot to re-add *.pyc into my .gcloudignore.
Another way to see the complete set of files included in an app deployment is to increase the verbosity to info on the gcloud app deploy command -- you see a giant json manifest with checksums. I don't typically leave that on because it's hard to visually inspect, but I would have spotted the .pyc in there.
I've been working on a small Google App Engine (standard environment) project that uses Cloud Endpoints v2. My code is largely based on the quickstart provided by Google.
Everything was working fine, but I re-deployed today after having not looked at it for a few weeks, and I'm getting the following error when I attempt to call the endpoint:
error: An error occured while connecting to the server: DNS lookup failed for URL: metadata.google.internal
This wasn't happening before. It seems to be happening when the endpoints package is being imported by Python.
My endpoint doesn't do anything fancy - I haven't changed the source from the sample EchoApi. The error ends up in the GCP Logging console no matter if I try to access the API through the API Explorer or via Curl.
I don't get any errors during deployment.
Edit #1
Some further information:
The error originates from within Google's code that is included with the google-endpoints package which I've included in my lib folder, per
the documentation. Specifically, the error occurs on line 54 of google/api/control/wsgi.py.
Basically, it's making a request to metadata.google.internal using urllib2.
I'm guessing this address is only available from within the Google Cloud, and that for whatever reason, the instance that's hosting my app can't do a DNS lookup on it.
Edit: #2
Dug a bit further.
It seems that the error originates in the google-endpoints-api-management package. Changes committed to that package on October 19th seem to have introduced additional platform reporting. metadata.google.internal is queried to check if the code is running within the Google Container Engine, then it blows up, because the metadata address doesn't resolve.
Here's the commit:
https://github.com/cloudendpoints/endpoints-management-python/commit/0a37d0e443091053ed03e455e06d3a0ae770999f
The google-endpoints package only requires google-endpoints-api-management >=1.0.0b1. On my end, things were working fine on version 1.0.0b2, but then I built a new lib folder, which brought down 1.0.0b5, and things went sideways. Required packages haven't changed between b2 and b5, so I'm thinking I may be able to just downgrade back to b2 for the time being. Haven't tried it yet.
Sent the Google Dev an email. Perhaps he'll chime in with further tips.
Edit: 2016-11-07
Tested downgrading the google-endpoints-api-management package to 1.0.0b2. Seems to be working, kludgy a fix as it is. If you're using the lib folder, the following will scrub the newer error-prone wsgi.py file and put back the older one:
pip install -t lib google-endpoints-api-management==1.0.0b2 --upgrade
Not pretty, but it may just get you back in business.
On a side note, the Google engineer promptly replied saying that he would take a look at this issue soon. With luck, endpoints v2 will eventually come out of beta, 'cause I'm really liking it so far.
This will be fixed in an upcoming patch to the google-endpoints-api-management package (which will be 1.0.0b6). It will probably be released sometime on Monday, 11/6.
If you'd like to continue testing right away and this error is blocking you, you can go back to 1.0.0b4 until 1.0.0b6 comes out. Everything should still work as normal with that version.
Thanks for bringing this to our attention! We're doing our best to iron out all of these wrinkles now during beta in preparation for our first general release.
EDIT: 1.0.0b6 has been released and resolves this issue. Thanks for your patience during our beta phase!
(Posted solution on behalf of the OP).
Google has released version 1.0.0b6 of the google-endpoints-api-management package to address this issue. It solved the problem for me. For anyone who is encountering this problem, clean out your lib folder and re-install the google-endpoints package. This will bring down the new google-endpoints-api-management package with it.
Thanks to Brad at Google for really quick action on this.
I had a Drupal website in drupal 6.x When i wanted to upgrade it to 7.x, the custom theme i was using was absolutely outdated, so i imported my Zen subtheme from another website. For doing that, i just copied the folders "zen" and "mytheme" from the other installation to this one. Then i selected "mytheme" as the current theme and changed some little things to adapt it.
The fact is now i'm experiencing the following problems:
I can't auto-update nothing. It downloads the files but then it stacks (and leaves the site in Maintenance Mode).
I can't run update.php. I can go on until i reach the "Run updates" step, which shows a blank screen. This is the main issue, i think, as it evidences -in my oppinion- a problem of communication between the site and the database.
In the Webform module i can't select "File" as a Field Type. This one is not that important, but it may be relevant for someone who knows more than me.
Edit:
Recently i migrated from a Shared to a VPS server. When i migrated, the subdomain in which i was experiencing the issue threw an incompatibility related to the lenght of the password of the database. I changed the password and it started to work again. This may help somebody for helping me. Thanks!
When i try to run gwt sample project it gives "RPC call failure.An error occurred while attempting to contact the server. Please check your network connection and try again". It was running good before but after i update programs and libraries it gives that error. Which update causes this error or there is other things?
Appengine version:1.7.0
GWT version:2.4.0
Eclipse version:4.2(juno)
JDK version:1.7.0_05
This may not be the problem you are facing but it seems to be the most frequent problem.
Let me predict - you last tried GWT four years ago and you hoarded the sample project hoping to pull it out one day.
And yesterday, you did pull it out. It kinda worked and then you decided to upgrade to the latest 2.4.0. (Actually the latest is 2.5.0-rc1).
Ooops. The web-inf/lib of your project is still faithfully using pre-version 2.2 gwt-servlet jar.
Nope, you can't do that. GWT-RPC data transfer format is version-unstable. Not guaranteed to be compatible from one version to the next.
Simple solution - recreate a new GWT project using the new Google plugin.
Then copy the src and web.xml of your project into the new project.
Or replace the gwt-servlet.jar with the latest. And if you usegwt-servlet-deps.jar, you would need to upgrade that too (but I doubt so, because if you did use gwt-servlet.deps.jar you wouldn't be asking this question).
But why would you keep the gwt sample from an old project?
The samples have remained quite the same over the years. Why not use the samples from the new GWT 2.4.0 download. You don't have to keep the samples. You should try to construct the projects for the samples afresh.
The GWT directory is found under Eclipse's plugins directory, under a long name. Like
plugins/com.google.gwt.eclipse.sdkbundle_2.4.0.v201205091048-rel-r37/gwt-2.4.0.
In which you will find the samples directory.