I have an application which contains a web application and a background worker.
I defined an AppHarbor.sln solution file, and included both projects. However, only the background worker gets deployed. Also, even the tests of the web application project seem to be ignored. I experimented with the project ordering in the solution file, but it's always the background worker that gets deployed.
Any ideas?
A free AppHarbor application only has a single worker associated by default. This can be either a background worker or a web worker (this is detected on the first successful build).
You probably just need to scale the number of web workers to 1 on the "Subscription" page, which will immediately trigger the deployment of the web application.
If the web application still isn't running you should check the build output to verify that it contains a web app.
AppHarbor has a FAQ which helps you troubleshoot problems like this. On your case I would recommend downloading the build output and verifying that everything is in order. Also feel free to contact AppHarbor support if you have any questions.
Related
I have been working on a polymer web app which I started in polymer 1.0
My problem is though i push new code some times the web app is in old version only. To solve the problem i disabled service worker(To avoid caching) and added time stamps to my back end APIs. Still I am facing the same problem.Suggest me solution.Also some times some elements don't respond and render.
Thanks in advance.
When you push new versions of your code, it doesn't automatically update the cached versions of those resources in the users' browsers. And I believe your service worker is coded to serve the cached resources, thus making your new versions of your code not served.
In order to serve the new versions, you need to make the service worker update its cached resources. This can be done by making the service worker cache the resources again (thus caching the new versions this time).
This can be done by making changes in your service worker file (even a single character change will do!). Once the users' browsers sees that the service worker has changed, it will download the updated service worker, run its install phase (thus caching the new versions of your resources).
If you can't decide what "change" to do in your service worker file, simply changing the cache name will do. Make sure to do this everytime you push new versions of your resources.
How do I start WebSphere 6.x admin service without starting my apps? Does anyone know how to do this (if its even possible)?
Since my app takes about 5+ minutes to start, I am hoping I can start the admin first , then login to the GUI and then manually start my app from the GUI. Another reason I want to do this is because the .ear update/upgrade process goes much faster if the app is turned off first and then I update the code and then I restart the app. If I try to update on the fly it seems to take much longer.
Change the default start up properties for the application to "Stopped".
The default is to start the applications as part of server start up.
Enterprise Applications --> Target Specific Application Status --> Disable Auto Start
I am assuming that you are a stand alone set up. If you are on ND environment, administration is essentially performed using the deployment manager and your application servers need not run for the activities to be performed.
Using the WebSphere Integrated Solutions Console, a large (18,400 file) web application is updated by specifying a war file name and going through the update screens and finally saving the configuration. The Solutions Console web UI spins a while, then it returns, at which point the user is able to start the web application.
If the application is started after the "successful update", it fails because the files that are the web application have not been exploded out to the deployment directory yet.
Experimentation indicates that it takes on the order of 12 minutes for the files to appear!
One more bit of background that may be significant: There are 19 application servers on this one WebSphere instance. WebSphere insists that there be a lot of chatter between them, even though they don't need anything from each other. I wondered if this might be slowing things down when it comes to deployment. Or if there's some timer in the bowels of WebSphere that is just set wrong (usual disclaimers apply...I'm just showing up and finding this situation...I didn't configure this installation).
Additional Information:
This is a Network Deployment configuration, and it's all on one physical host.
* ND 6.1.0.23
Is this a standalone or a ND set up? I am guessing it is ND set up considering you have stated that they are 19 app servers. The nodes should be synchronized with the deployment manager so that the updated files are available to the respective nodes.
After you update and save the changes, try and synchronize the nodes with the dmgr (or alternatively as part of the update process, click on review and the check the box which says synchronize nodes) and this would distribute the changes to the various nodes.
The default interval, i believe is 1 minute.
12 minutes certainly sounds a lot. Is there any possibility of network being an issue here?
HTH
Manglu
I'm using System.Runtime.Caching.MemoryCache to simulate a repeated task on a running .NET MVC application deployed on AppHarbor.
Entries in the cache are added using a CacheItemPolicy which contains an AbsoluteExpiration offset and a RemovedCallback that calls a method and retriggers the adding of the item in the cache (as described here)
MemoryCache is populated first time in Application_Start. It works fine locally, but doesn't seem to work once deployed on AppHarbor (tried also with HttpRuntime.Cache, same result).
My application is running under a CANOE (free) account on AppHarbor that only has one worker. Does this mean that I won't be able to simulate the background task until I upgrade to some paid plan?
Thanks!
Your application has to have visitors every once in a while for this to work. Other than StillAlive, Pingdom is also a good bet for generating requests to your app. You should also take a look at MomentApp. We expect to have background tasks ready shortly.
I don't think upgrading will help, they are working on adding background jobs to AppHarbor but to my knowledge they available yet.
What about using a service like https://stillalive.com/ to periodically hit a page on your site that then spins up a new thread and starts running your background task? Its available as a free add-on.
I was thinking of doing something like this while waiting for the background task functionality to be available.
Is there a way to get a scheduled job to run on a single server? We have an email sending job that I don't want running twice simultaneously. Is this what heroku workers are for? I am currently under the impression that play! jobs actually run on web workers. Thanks!
We've been using Play! (not on Heroku) and found the easiest way was to define a framework id for the servers you want to run the jobs, and a framework id for the servers that won't run the jobs.
In our case, "prodapp" are the Production Application servers that don't run jobs, and "prodadmin" is the Production Admin/Job server (only one).
We've included the following in our application.conf to disable the jobs plugin on the prodapp servers:
%prodapp.plugins.disable=play.jobs.JobsPlugin
I'm not sure it's the best solution, but after investigating some other options, we determined it to be the quickest to implement without forking the Play! source code.
I sent a support ticket to Heroku for the same query. They advised not to use Play scheduled jobs, but to instead use the Scheduler add-on instead.
I don't think you can specify a server id within Heroku, so you cannot distinguish one web server from another, and therefore cannot only use one instance for jobs like you could if you had control over the number of servers you were spinning up.