Thanks Roberto,
I ran the app with the following command. In the logs entry of POST it
shows collecting the data, but the subsequent page AFTER data is
collected, that does not display, Still.
Will also try to run the previous application, which was running on apache+wsgi.
====================================================================
# uwsgi --http :9090 --wsgi-file index.py --master --processes 4 --threads 2
*** Starting uWSGI 2.0.7 (64bit) on [Mon Oct 20 16:15:26 2014] ***
compiled with version: 4.8.2 on 19 October 2014 01:19:43
os: Linux-3.16.1-031601-generic #201408140014 SMP Thu Aug 14 04:15:26 UTC 2014
nodename: nitin
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /home/nitin/finhealth
detected binary path: /usr/local/bin/uwsgi
your processes number limit is 15092
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :9090 fd 4
uwsgi socket 0 bound to TCP address 127.0.0.1:36174 (port auto-assigned) fd 3
Python version: 2.7.6 (default, Mar 22 2014, 23:03:41) [GCC 4.8.2]
Python main interpreter initialized at 0x12b2ff0
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 415360 bytes (405 KB) for 8 cores
*** Operational MODE: preforking+threaded ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x12b2ff0
pid: 6594 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 6594)
spawned uWSGI worker 1 (pid: 6595, cores: 2)
spawned uWSGI worker 2 (pid: 6596, cores: 2)
spawned uWSGI worker 3 (pid: 6597, cores: 2)
spawned uWSGI worker 4 (pid: 6598, cores: 2)
spawned uWSGI http 1 (pid: 6601)
[pid: 6597|app: 0|req: 1/1] 127.0.0.1 () {34 vars in 572 bytes} [Mon
Oct 20 16:15:35 2014] GET / => generated 2233 bytes in 0 msecs
(HTTP/1.1 200) 2 headers in 66 bytes (1 switches on core 0)
[pid: 6597|app: 0|req: 2/2] 127.0.0.1 () {34 vars in 523 bytes} [Mon
Oct 20 16:15:35 2014] GET /favicon.ico => generated 2233 bytes in 0
msecs (HTTP/1.1 200) 2 headers in 66 bytes (1 switches on core 0)
[pid: 6598|app: 0|req: 1/3] 127.0.0.1 () {36 vars in 603 bytes} [Mon
Oct 20 16:15:39 2014] GET / => generated 2233 bytes in 0 msecs
(HTTP/1.1 200) 2 headers in 66 bytes (1 switches on core 0)
[pid: 6595|app: 0|req: 1/4] 127.0.0.1 () {34 vars in 523 bytes} [Mon
Oct 20 16:15:39 2014] GET /favicon.ico => generated 2233 bytes in 0
msecs (HTTP/1.1 200) 2 headers in 66 bytes (1 switches on core 0)
[pid: 6598|app: 0|req: 2/5] 127.0.0.1 () {44 vars in 769 bytes} [Mon
Oct 20 16:15:56 2014] POST /insertCash.py => generated 2233 bytes in 0
msecs (HTTP/1.1 200) 2 headers in 66 bytes (1 switches on core 0)
[pid: 6598|app: 0|req: 3/6] 127.0.0.1 () {34 vars in 523 bytes} [Mon
Oct 20 16:15:56 2014] GET /favicon.ico => generated 2233 bytes in 0
msecs (HTTP/1.1 200) 2 headers in 66 bytes (1 switches on core 1)
^CSIGINT/SIGQUIT received...killing workers...
gateway "uWSGI http 1" has been buried (pid: 6601)
worker 2 buried after 0 seconds
worker 4 buried after 0 seconds
worker 1 buried after 1 seconds
worker 3 buried after 1 seconds
goodbye to uWSGI.
On 20 October 2014 15:37, Roberto De Ioris <[email protected]> wrote:
>
>> I started with just the wsgi config lines, not the cgi. As I kept
>> testing the possibility of things working, as desperate it sounds and
>> looks stupid, I kept adding cgi config lines.
>>
>> In one of the previous projects which I developed, I was using wsgi
>> with apache2.2. The complete application worked. All links, DB
>> connectivity, insertions and retrievals, web forms and reports on a
>> web page. All static web pages.
>>
>> I did use
>>
>> import cgi
>>
>> and the same coding syntax in the python scripts. As posted earlier.
>>
>> Now I am looking to migrate the same application along with developing
>> a new one to nginx+uwsgi (future on docker) .... and that is where I
>> am facing this issue.
>>
>> WSGI quick start was one of the pages I referred while configuring the
>> web server, with no luck.
>>
>> I buzzed the list after I just could not understand any way, what am I
>> missing in configuring nginx or uwsgi or both.
>>
>> Now also Individual pages work, but when I click on submit on index
>> page form, the subsequent page does not 'display', IT still shows the
>> index form page albeit, blank (refresh / reloaded). So, what do I
>> need to change in the config file(s) so that the complete application
>> works as desired, on clicking the links / submit ?
>>
>> Please bear with me, I can be slow at times.
>>
>> Thanks
>>
>
> If you are already using mod_wsgi, then you only need the python/wsgi
> plugin, you do not want cgi.
>
> Now, start following (from the beginning) the WSGI quickstart and write
> here when you are blocked, describing the step you did and how they
> failed. This will eventually help in improving the quickstart too
>
> --
> Roberto De Ioris
> http://unbit.it
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
