1 Reply Latest reply: Jul 25, 2013 4:56 PM by pthaden-Oracle RSS

    503 Service Unavailable for REST calls with ApEx Listener 2.0.2 DB 12c

    pthaden-Oracle

      Hi, posting in case you come across this too.  After installing the 2.0.2 Listener in front of ApEx in a new 12c database all was working well until I tried to use the RESTful services URIs that are part of the oracle.example.hr module.  When I'd try to test any of the handlers such as https://host:port/apex/workspace/hr/employees/ it would return 503 Service Unavailable errors.

       

      I tried a lot of troubleshooting, including granting "connect through apex_rest_public_user" per Apex Listener 2.0 RESTful services  error 503 and even upgrading my 12c Apex to 4.2.2, but still kept getting the 503 errors.  It happened only for the RESTful service URIs, although at the same time I also tried to connect to the listener via SQLDeveloper and would get the 503 errors there (even after creating my adminlistener user).

       

      Meanwhile the regular (non-RESTful) ApEx URIs were working fine.  This seemed to point to a configuration issue or bad password keyed when running the @apex_rest_config.sql script, but no matter how many times I re-ran that script and no matter how carefully I typed the passwords, the 503 errors remained.  I double-checked in dba_users and found the apex_listener, apex_rest_public_user were unlocked and I could even connect to those schemas with SQLDev, so it wasn't a password issue.

       

      I got this same behavior whether I deployed to WebLogic or if I ran the listener in standalone mode.  The break came when I enabled <entry key="debug.printDebugToScreen">true</entry> inside of the Listener's defaults.xml.  Now I was throwing errors that pointed at the connections defined when I ran java -jar apex.war setup:

       

      • ...
      • Caused by: oracle.dbtools.common.jdbc.ConnectionPoolException: The pool named: apex_al is not correctly configured, error: Listener refused the connection with the following error:
      • ORA-12514, TNS:listener does not currently know of service requested in connect descriptor
      • ...

       

      I had a look at my apex_listener/apex/conf/apex_al.xml file and compared it with the working apex.xml file.  I think these are the files generated by java -jar apex.war setup.  My apex_al.xml file was much smaller:  it only had entries for db.password and db.username, while the apex.xml file had these entries plus ones for db.hostname, db.sid and db.servicename.  I modified the apex_al.xml file to match the apex.xml file by adding entries for sid, servicename and hostname:

       

      /apex_listener/apex/conf/apex_al.xml:

       

      <?xml version="1.0" encoding="UTF-8" standalone="no"?>

      <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">

      <properties>

      <comment>Saved on Wed Jul 24 17:42:05 EDT 2013</comment>

      <entry key="db.sid">mysid</entry>

      <entry key="db.servicename">myservicename.com</entry>

      <entry key="db.password">@FUNKY3NCRYP3DP455W0RD</entry>

      <entry key="db.username">APEX_LISTENER</entry>

      <entry key="db.hostname">myhostname.domain.com</entry>

      </properties>

       

      After restarting the listener, I threw a similar error but this time for apex_rt, so I did the same steps above to the apex_listener/apex/conf/apex_rt.xml file.

       

      Changing both files to include sid, servicename and hostname info and restarting the listener did the trick.  This also fixed my 503 errors in SQLDeveloper when connecting directly to the Listener.

       

      Not sure if sid and servicename both need to be there or which one takes precedence, but it's likely that I populated both into the apex.xml in one of the many times I re-ran the java -jar apex.war setup command. 

       

      HTH,

      -paul

        • 1. Re: 503 Service Unavailable for REST calls with ApEx Listener 2.0.2 DB 12c
          pthaden-Oracle

          A followup:

           

          I got better information later, and it turns out the root of my problem was in my defaults.xml file (for me it's in /apex_listener/apex/defaults.xml).  In there I had mistakenly given the wrong servicename when I first set up the Listener, and it stuck. 

           

          When the conf/apex.xml file later got updated with the corrected servicename, the regular ApEx pages started working just fine through the Listener because they overrode the defaults.xml.  Then I edited the conf/apex_al.xml and conf/apex_rt.xml by hand to match, and all was well.

           

          If I had instead edited the defaults.xml and corrected the wrong db.servicename entry, there wouldn't have been a need to override it with hand-edits to the apex_al and apex_rt files.  I just tested this:  corrected the defaults.xml db.servicename entry and removed my hand-edits to the other files.  After restarting the Listener, it's working fine with RESTful URIs.

           

          Alternatively, if I had chucked my entire apex_listener directory and started over from scratch, I would have gotten a clean slate and probably wouldn't have mistyped the servicename.

           

          Live and learn,

          -paul