Tag: error

  • 503 Service Unavailable: ORDS unable to make a connection…all connections in the Univeral connection Pool are in use – [30,30,42….]

    Have you ever seen this?

    Have you ever seen a message like this while working with ORDS? The one where you receive a 503 Service Unavailable response code and message?

    This message has something to do with ORDS being unable to make a connection to the database.

    But if you keep reading, you’ll see even more information- something related to the Universal Connection Pool- followed by an array of numbers. Did you know that the “stuff” in that array is actually helpful information?

    Well…Kris knew.

    What does it all mean?

    But for the rest of us plebes, what does “max = 30 and current in use = 30” refer to? Well, let’s figure it out!

    Take a closer look at the above image. You’ll see an array consisting of the following: [30, 30, 42, 12, 0, 30, 1, 0, 29]. Which, according to the Universal Connection Pool documentation, translates to:

    Now what?

    So, what do we do with this information? Well, it depends. In this case, it looks like available connections were exhausted. And what could cause that? It’s a mystery, but it doesn’t have to be 😉. You need to do some exploring (It’s not just going to fix itself.)!

    Luckily, there are many ways to “peek under the covers” to learn what is happening in and around your database. Some things that come to mind:

    These are the ones that I’m most familiar. But if you are reading this, what works for you? Drop a comment on what tools you use, and I’ll update this post for others to see!

    When you’re ready…

    Once you’ve determined what is happening, you can return to ORDS and tweak your JDBC settings—if you need to!

    That’s all folks

    This post is outside the norm of what I usually post. I’m not doing a walkthrough or tutorial. I’m just…throwing some info out there. I mainly wanted to write this quick PSA before I forgot.

    I’ve seen this error come up frequently in questions. I think if more people knew what those numbers meant, it might help with self-diagnosis. I hope I’m not wrong. Catch you later 😎!

    Follow

    And don’t forget to follow, like, subscribe, share, taunt, troll, or stalk me!

  • ORDS WARNING Cannot find the real static path of

    ORDS WARNING Cannot find the real static path of

    Problem description

    You’ve just upgraded ORDS and issued the ords serve command. As ORDS is starting up, you see the following warning (or something like it):

    WARNING Cannot find the real static path of https://static.oracle.com/cdn/23.2.0/

    How to fix

    Easy! In this case, I removed the standalone.static.path property of the ORDS Global configuration settings.

    Removing ORDS configuration settings

    You can remove/add/update ORDS configuration settings in two ways:

    1. Manipulating the Global settings.xml file directly, or
    2. Using the ORDS CLI
    NOTE: Using the ORDS CLI is the preferred method. I cannot stress this enough. 

    Whenever an ORDS installation or upgrade displays errors or warnings, go straight to the ORDS upgrade logs. Review the associated log for anything out of place and anything relevant to the warning or error you observed. In this case, the error pointed to two clues:

    1. APEX
    2. “static path”
    REMEMBER: When you are troublshooting, you are on a fact-finding mission. You're looking for clues that can help you solve a mystery. 

    Here, I see that APEX isn’t even installed in my target database. Perhaps Chris was trying to do something with/in APEX in the past and got distracted.

    Since it looks like I haven’t installed APEX, I feel comfortable ruling out APEX as the culprit.

    More than likely, this is pointing toward user error as the culprit. Perhaps it was some setting that I applied incorrectly. Next, I’ll inspect the Global configuration settings for ORDS. I can do this in two ways:

    1. A visual inspection of the settings.xml file
    2. Or using the ORDS CLI

    Visual inspection

    Immediately, you can see the offending configuration property: standalone.static.path. This property “specifies the path to the folder containing static resources required by APEX.”1 Since I am reasonably sure that APEX doesn’t exist, nor does any APEX metadata exist in my database, I can test my theory by removing the property from the settings.xml file.

    I can do this pretty quickly in a text editor. However, if you are skittish about manipulating these files directly (and rightfully so), then use the ORDS CLI (this is the preferred method anyway).

    Updating settings with the ORDS CLI

    In this case, you’ll see a fictitious standalone.static.path directory, /123456/abcdef.

    You can easily remove this, and other settings with the delete option.

    The command used in this example:

    ords config delete standalone.static.path

    Once you’ve made the change, close out your Terminal session and start a new one. Closing out your session and restarting with a new one is good practice to ensure that your Terminal session recognizes any configuration changes you’ve made.

    I next issued the ords serve command and ORDS started up with no problem.

    And that is how we fixed this warning in this oddly specific scenario. I hope this helped!

    And one more thing

    You may have noticed I’m on ORDS Version 24.4. That is because I was using a pre-release version that will be available when this post is published. So, if you haven’t done so yet, download the latest ORDS here.

    Follow

    And don’t forget to follow, like, subscribe, share, taunt, troll, or stalk me!

    1. See Table C-1 in the ORDS Installation and Configuration Guide. ↩︎