Wednesday, February 25, 2015

Re: OperationalError: ORA-03114: not connected to ORACLE.

Hi Alex,

Correct. There seems to be something wrong with the configuration of mod_wsgi, because you are able to connect via dbshell (which loads all of your environment variables and is able to connect). The same thing with runserver. 

Check for a good tutorial on how to configure apache + mod_wsgi. Also check in the logs for mod_wsgi. There probably are some configuration issues that are easy to solve.

Regards,

Andréas

2015-02-25 11:51 GMT+01:00 <alexandrosstylianou88@gmail.com>:
Hi Andreas,

I did the following test... i used "python manage.py runserver" and i was able to use the admin page (http://127.0.0.1:8000/admin/) of Django and log into the DB. 

So that means the apache and the mod_wsgi as you said have a problem, correct ???

Regars,
Alex

On Tuesday, February 24, 2015 at 6:05:14 PM UTC+2, Andréas Kühne wrote:
The file you wrote connects to the database itself, it doesn't use djangos connection, so the only thing you are testing is if you can connect to the database. And that we know (because you are able to do it with ./manage.py dbshell). What you need to check is if the settings.py file used by django is correctly interpreted by mod_wsgi. 

Because you are bepassing all of that, your test file will work and just connects to the database.

As I said earlier, make sure that your mod_wsgi is configured correctly and that it can read your settings file.

Regards,

Andréas

2015-02-24 16:19 GMT+01:00 <alexandros...@gmail.com>:
Well i have created the below test script to check if i am able to connect to the DB using mod_wsgi and i get back the sysdate from the DB.. I have configured mod_wsgi under the alias /test to execute the below script and i always get the time..  So it seems that the configuration in mod_wsgi is correct
------------------------
import os,sys

import cx_Oracle


con = cx_Oracle.connect("username/password@DB")
print('DATABASE VERSION: ' + con.version)
print ''

time= con.cursor()
time.execute("SELECT TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') FROM DUAL")

for t in time:
    print t

con.close()

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World! \r\r'
    output += str(t)
    #print sys.stderr

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]

    start_response(status, response_headers)

    return [output]


-----------------------------


On Tuesday, February 24, 2015 at 4:21:01 PM UTC+2, Andréas Kühne wrote:
Hmmm

You can use ./manage.py dbshell, so your configuration is correct in THAT case, however, have you set all the variables correctly for django when running apache + mod_wsgi? Has the connection ever worked there?

What do the config files for mod_wsgi look like and are all of the paths correctly set in the mod_wsgi script?

I'm just guessing now, but I think that the problem is your mod_wsgi setup.

Regards,

Andréas 

2015-02-24 14:17 GMT+01:00 <alexandros...@gmail.com>:
Is there any way to find out where the problem occurs ?? Is there a way to enable some debugging or trace in order to see which python scripts are called in Django and find out where the whole process is failing ??

In the last lines of the stack trace it tries to close the connection and for some reason it fails... is it because the connection was never created ?? or it was closed before the application was ready to send data.. ???

Can anyone help ????

On Tuesday, February 24, 2015 at 2:08:53 PM UTC+2, Andréas Kühne wrote:
The reason I asked this is because that means that your connection parameters are correct, so it should work?

Sorry I don't know what to do to help you more.

Regards,

Andréas

2015-02-24 12:49 GMT+01:00 <alexandros...@gmail.com>:
Hi Andreas,

I can connect using "python manage.py dbshell" it connects without any error.

Is there a difference, if i am not mistaken the dbshell test shows that the configuration of the DB is correct and that i can connect from the machine, correct ?? From the stack trace it seems that the real issue is not returned and the only thing i get is the "NOT CONNECTED TO ORACLE" error


Regards,
Alex

On Friday, February 20, 2015 at 7:12:05 PM UTC+2, Andréas Kühne wrote:

2015-02-20 17:18 GMT+01:00 <alexandros...@gmail.com>:
Hi,

I migrated my project to a new infrastructure but i kept the same versions Apache 2.2 + mod_wsgi + python 2.6.1 + Django 1.2.1 

I am trying to run my project and i am getting the below exception that seems to be from Django and i need help pin pointing the exact cause, because i think that the actual exception is never caught and returned to the log and all i am getting is the OperationalError: ORA-03114: not connected to ORACLE. I checked the Oracle DB and i can connect to it.

[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] mod_wsgi (pid=27565): Exception occurred processing WSGI script '/opt/wgt_proxy/wgtproxyProj/wgtproxy/apache/django.wsgi'.
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] Traceback (most recent call last):
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File "/opt/wgt_proxy/wgtproxyProj/wgtproxy/apache/django.wsgi", line 50, in __call__
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     return self.__application(environ, _start_response)
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File "/opt/webtier/python_64/lib/python2.6/site-packages/django/core/handlers/wsgi.py", line 248, in __call__
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     signals.request_finished.send(sender=self.__class__)
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File "/opt/webtier/python_64/lib/python2.6/site-packages/django/dispatch/dispatcher.py", line 162, in send
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     response = receiver(signal=self, sender=sender, **named)
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File "/opt/webtier/python_64/lib/python2.6/site-packages/django/db/__init__.py", line 82, in close_connection
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     conn.close()
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]   File "/opt/webtier/python_64/lib/python2.6/site-packages/django/db/backends/__init__.py", line 70, in close
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]     self.connection.close()
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] OperationalError: ORA-03114: not connected to ORACLE
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx]
[Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] Request Failed for : /wgtproxy/admin/, Resp Code : [500]

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/88d2de85-f330-4c35-9818-9c19addcc1cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

What happens if you try to do "python manage.py dbshell"? Are you able to connect to the database then?

Regards,

Andréas

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/71056041-36f4-4392-9303-4775dc80a510%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8169e731-f541-4694-be17-c170b9effafe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e3b9bb59-d753-4b6f-9e13-6bbcb72f1ef8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f63dc944-ef4a-4cd2-93cd-31bcfb2237fb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALXYUbkua74y4Lk48U%2BeQkc3A2w7NGHnKN2uzJGNjPCtWb-kNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment