I use openshift to run a script from time to time with the cron cartridge.
however, as my application has no web activity (yet) it goes idle and my process doesn't run.
one could think of an ugly solution to generate fake web-load by using another service (such as ifttt to retrieve a page constantly but this sounds wrong.
could there be a better solution?
apparently the only way is to trick openshift to have out-coming traffic, I used a free account of https://www.site24x7.com for that
OpenShift will idle your application after 24 hours of inactivity1, but you can add an hourly cron job to your app to keep itself alive.
.openshift/cron/hourly/ping.sh
#!/bin/bash
PATH=/bin:/usr/bin:/usr/sbin
app_url=http://$OPENSHIFT_APP_DNS/
curl --insecure --location --silent --fail "$app_url" >/dev/null
Assuming your app isn't already idled and won't run the cron job :-)
1 Apparently the idle period used to be 48 hours before, but now it is 24 hours according to the OpenShift pricing table. In other words, a daily pinger cron job won't do it for you.
Openshift cartridge goes idle after 24 hours of inactivity.
Activity is considered receiving a Get request in your application originated outside your cartridge (so pinging your app from your own cartridge doesn’t work).
You can use any free pinging service to ping your application after a specific interval of time(< 24hrs).
You may use Pingdom. I have found success using it. It provides a nice dashboard and graphs of response time as well. You will be notified if there is any issues connecting to your app or if its down. You can manage your account with their mobile apps.
There are other free pinging services too. Feel free to Google and try out other services. Do comment if you find a good one, might be a great help for some :-).
It's not really a "trick" per se, but as long as you have consistent incoming traffic, your gear will not idle.
Bronze is free. All plans retain the free stuff, e.g. 3 free gears etc. you will only pay $0.02 hr on gears above 3.
So if you are using the free tear and not using 3 gears you should be safe to upgrade to bronze and remain free.
In your nodejs app:
Create an httpserver able to dispatch a get request page
Include a cron job into your array job list that every hour send a post to external page (php,jsp or every kind of "page" that can create a curl request).
In external page:
Execute the logic of a job (optional because you can use job2, job3..jobn and leave this job just for hold your app awake)
Insert somewhere in the code a request back to nodejs server page using php curl library.
In this case:
At every hour, idle timeout will be reset and your application stay awake
You can decide to put jobs in external pages and/or nodejs
Hope it helps someone.
EDIT: I'm sorry, it's not working anymore. No matter which kind of strategy you use, they will be able to discover systematic requests coming from a specific IP and exclude this situation, bringing your app idle for earn money, because everybody know that BRONZE is not FREE. It costs at least 0.02$/hour.
Related
We want to use ejabberd in the context of a web application having fairly unique and business rules, we'd therefore need to have every chat message (not protocol message, but message a user sends to another one) go through our web application first, and then have the web application deliver the message to ejabberd on behalf of the user (if our business rules allow the message to be sent).
The web application is also the one providing the contact lists (called rosters if I understand correctly to ejabberd). We need to be and remain the single source of truth to ease maintenance.
To us, ejabberd value added would be to deliver chat messages in near real-time to clients, and enable cool things such as presence indicators. Web clients will maintain a direct connection to ejabberd through websocket, but this connection will have to be read-only as far as chat messages are concerned, and read-write as far as presence messages are concerned.
The situation is similar with regards to audio and video calls. While this time the call per see will directly be managed by ejabberd to take advantage of built-in STURN, TURN etc... and will not need to go through our web app, we have custom business logic to manage who is able to call who, when, how often etc... (so in order words, we have custom business logic to authorize the call or not and we'd like to keep all the business logic centralized in the web app).
My question is what would be the proper hooks we'd need to look into to achieve what we are after? I spent an hour or so in the documentation, but I couldn't find what I am after so hopefully someone can provide me pointers. In an ideal world, we'd like to expose API endpoints from our web app that ejabberd hooks can hit. However, the first question is: which relevant hooks is ejabberd offering and where are these hooks documented?
Any help would be greatly appreciated, thank you!
When a client sends a packet to ejabberd, it triggers the user_send_packet hook, providing the packet and the state of the client's session process. Several modules use that hook, for example mod_service_log.
For about a week now, it says:
Queued for provisioning
Due to an increase in OpenShift Online Starter popularity, please
expect a longer delay in account provisioning. You will receive an
email when there is enough capacity to add your account. Thank you for
your patience!
Two weeks!
It took two weeks for Red Hat to finally provision the account. Yesterday I finally received an email:
Your OpenShift Online account is ready!
Obviously I had already moved to another provider in the meantime.
(Note that the status page had not displayed any technical reasoning for the delays. It was "all green". It's pretty obvious that this is just tactics to avoid getting users on the free tier.)
I'm developing a web app that need work on-line and when the coonection is not available, so i would like to say how the best way to synchronization my requests when on-line again. I see some things about Service Workers, but i don't know if it is the best.
You can definitely use service workers for this use case!
The particular solution will depend on your specific needs (service workers are pretty generic).
A possible approach would be a "request deferrer", like the one implemented in the ServiceWorker Cookbook. In this solution, while the user is offline, requests to the server are queued and, when the user goes back online, the queued requests are actually executed against the server.
I'm using small webapp which is hosted on openshift and that app is actually a web-serviсe. Sinse my app is scalable it is maintained by haproxy load baloancer. But I noticed that my app was hibernated after some period of time.
Why does it happen?
Is haproxy able to maintaine web-service application?
as it turned out there were just terminology problems as scalable does not mean that it will not idling. thus the issue has been resolved.
As said here "Openshift suspends and serializes apps without much activity after a given period, and the first time they 'wake' they deserialize and this takes time."
I’ve been developing Windows desktop applications for many years, but just started developing Windows Phone 8 applications so, as you can imagine, I have many questions and doubts.
This is my problem so far:
I need an application to check any certain time if there are new messages / notifications in the server database, even if the application is not running, and show it (in some way, not sure how) on the phone. At the end, I want something similar to Facebook application (or others) that checks constantly if there are new messages even if I’m not using the phone.
How can I do that? Is there any tutorial or guide that explains that?
Thank you very much
There's two mechanisms available on Windows Phone to periodically check a data source and display notifications:
Push notifications: the server directly sends the notification to the phone. It provides the best user experience, because the notification is send (nearly) instantaneously, and because all the processing is done server-side (so it doesn't impact the phone's autonomy). The obvious drawback is that you need a server infrastructure to send the notifications.
Background agents: your application runs in background, is woke up periodically (every 30 minutes or so), and is allowed to run for about 15 seconds. During those 15 seconds, you can check your data source, and display a notification if needed. The two major drawbacks are that you can't choose when you're background agent executes (so the notification can be displayed 30 minutes late), and it'll have an impact on the battery life.
What you need is push notifications.
Microsoft already provides this functionality throught Azure Mobile Services and here is something to get you started : Get started with push notifications in Mobile Services