From ef227670c24ca6ba16f1574b4c5396fb6072487a Mon Sep 17 00:00:00 2001 From: Aarni Koskela Date: Sun, 19 May 2013 16:42:43 +0300 Subject: [PATCH] infos -> information --- Async.rst | 15 ++++++--------- Changelog-1.9.7.rst | 2 +- Changelog-1.9.rst | 2 +- Emperor.rst | 2 +- InternalRouting.rst | 2 +- JVM.rst | 2 +- Legion.rst | 2 +- Ring.rst | 2 +- WSGIquickstart.rst | 2 +- tutorials/heroku_python.rst | 2 +- 10 files changed, 15 insertions(+), 18 deletions(-) diff --git a/Async.rst b/Async.rst index c5f560a1..1bf203b2 100644 --- a/Async.rst +++ b/Async.rst @@ -23,13 +23,10 @@ the ``--async `` option Currently the uWSGI distribution includes the following suspend/resume engines: -``uGreen`` Unbit greenthreads implementation (based on swapcontext() ) - -``Greenlet`` Python greenlet module - -``Stackless`` Stackless python - -``Fiber`` Ruby 1.9 fibers +* ``uGreen`` - Unbit's greenthread implementation (based on `swapcontext()`) +* ``Greenlet`` - Python greenlet module +* ``Stackless`` Stackless Åython +* ``Fiber`` - Ruby 1.9 fibers Running the uWSGI async mode without a proper suspend/resume engine will raise a warning, so for a minimal non-blocking app you will need something like that: @@ -39,8 +36,8 @@ you will need something like that: uwsgi --async 100 --ugreen --socket :3031 An important aspect of suspend/resume engines is that they can easily destroy your process if it is not aware of them. -Some of the language plugins (most-notably python) has hooks to cooperate flawlessly with coroutine/greenthreads. Other languages -may fail miserably. Always check the uWSGI mailinglist or irc channel for updated infos. +Some of the language plugins (most notably Python) has hooks to cooperate flawlessly with coroutine/greenthreads. Other languages +may fail miserably. Always check the uWSGI mailing list or IRC channel for updated information. Older uWSGI releases supported an additional system: callbacks. diff --git a/Changelog-1.9.7.rst b/Changelog-1.9.7.rst index 5457a79b..ef850c8d 100644 --- a/Changelog-1.9.7.rst +++ b/Changelog-1.9.7.rst @@ -139,7 +139,7 @@ For example you can monitor (and throw an alarm) when your cgroup is running the in this example CGROUP_OOM_FD is an environment variable mapping to the number of an eventfd() filedescriptor inherited from some kind of startup script. Maybe (in the near future) we could be able to directly define this kind of monitor directly in uWSGI. -More infos on the eventfd() + cgroup integration are here: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt +More information on the eventfd() + cgroup integration are here: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt an example perl startup script: diff --git a/Changelog-1.9.rst b/Changelog-1.9.rst index 47c3f130..4fa95a3f 100644 --- a/Changelog-1.9.rst +++ b/Changelog-1.9.rst @@ -244,7 +244,7 @@ As well as the request body language-independent management, an exception manage Currently supported only in the Python and Ruby plugins, allows language-independent handling of exceptions cases (like reloading on a specific exception). -The --catch-exception option has been improved to show lot of useful infos. Just try it (in development !!!) +The --catch-exception option has been improved to show lot of useful information. Just try it (in development !!!) Future development will allow automatic sending of exception to system like Sentry or Airbrake. diff --git a/Emperor.rst b/Emperor.rst index 66b36fd2..6fc95ae0 100644 --- a/Emperor.rst +++ b/Emperor.rst @@ -99,7 +99,7 @@ On demand vassals (socket activation) ------------------------------------- Inspired by the venerable xinetd/inetd approach, you can spawn your vassals only after the first connection -to a specific socket. This feature is available since 1.9.1, check its changelog for more infos: +to a specific socket. This feature is available since 1.9.1, check its changelog for more information: :doc:`Changelog-1.9.1` diff --git a/InternalRouting.rst b/InternalRouting.rst index 7e52ee88..3361e110 100644 --- a/InternalRouting.rst +++ b/InternalRouting.rst @@ -161,7 +161,7 @@ base64, encode the specified var in base64 hex, encode the specified var in hex -uwsgi, return internal uWSGI infos, uwsgi[wid] and uwsgi[pid] are currently supported +uwsgi, return internal uWSGI information, uwsgi[wid] and uwsgi[pid] are currently supported Is not --route-if enough ? Why --route-uri and friends ? diff --git a/JVM.rst b/JVM.rst index 1075f92f..52458bba 100644 --- a/JVM.rst +++ b/JVM.rst @@ -16,7 +16,7 @@ Building the JVM support First of all, be sure to have a full JDK distibution installed. The uWSGI build system will try to detect common JDK setup (debian,ubuntu,centos, OSX...), but if it is not able -to find a JDK installation it will need infos from the user (see below). +to find a JDK installation it will need information from the user (see below). To build the JVM plugin simply run: diff --git a/Legion.rst b/Legion.rst index 965f4ded..ed05313e 100644 --- a/Legion.rst +++ b/Legion.rst @@ -239,7 +239,7 @@ Obviously more api functions will be added in the future, feel free to expose yo Stats ***** -The Legion infos are exported in the :doc:`StatsServer` +The Legion information are exported in the :doc:`StatsServer` Be sure to understand the difference between "nodes" and "members". Nodes are the peer you configure with the **legion-node** option while members are the effective nodes that joined the cluster. diff --git a/Ring.rst b/Ring.rst index 48069048..e46b345c 100644 --- a/Ring.rst +++ b/Ring.rst @@ -24,7 +24,7 @@ java-1.6.0-openjdk.x86_64-devel or java-1.7.0-openjdk-devel.x86_64 or on debian/ OSX/X-Code default paths are searched too. -For more infos on the JVM plugin check :doc:`JVM` +For more information on the JVM plugin check :doc:`JVM` After a successfull build you will have the uwsgi binary and a uwsgi.jar file that you should copy in your CLASSPATH (or just remember to set it in the uwsgi configuration everytime). diff --git a/WSGIquickstart.rst b/WSGIquickstart.rst index 2dbac622..e9179c7e 100644 --- a/WSGIquickstart.rst +++ b/WSGIquickstart.rst @@ -106,7 +106,7 @@ The stats subsystem allows you to export uWSGI internal statistics via json uwsgi --http :9090 --wsgi-file foobar.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191 -make some request to your app and then telnet to the port 9191. You will get lot of funny infos. +make some request to your app and then telnet to the port 9191. You will get lot of funny information. There is a top-like tool for monitoring instances, named 'uwsgitop' (just pip install it) diff --git a/tutorials/heroku_python.rst b/tutorials/heroku_python.rst index 4ef397af..065de511 100644 --- a/tutorials/heroku_python.rst +++ b/tutorials/heroku_python.rst @@ -104,7 +104,7 @@ Following push will be much faster. Checking your app ***************** -Running ``heroku logs`` you will be able to access uWSGI logs. You should get all of your familiar infos, and eventually +Running ``heroku logs`` you will be able to access uWSGI logs. You should get all of your familiar information, and eventually some hint in case of problems. Using another version of python