Monday 24 May 2010

ADF and WLS JNDI configuration errors

Another blog under the theme "let's document it so we don't get caught out again", which can also be tagged as "let's document it so others don't get caught out too".

In our Oracle JDeveloper 11g ADF applications at runtime, on occasion we encountered one of the following errors when running our applications under Oracle's WebLogic Server 10.3.2. I've included the beginning stack trace to assist Google searches into this page:

<Utils><buildFacesMessage> ADF: Adding the following JSF error message: JNDI failure. Unable to lookup Data Source at context jdbc/SomeJndi
oracle.jbo.DMLException: JBO-27200: JNDI failure. Unable to lookup Data Source at context jdbc/SomeJndi
at oracle.jbo.server.DBTransactionImpl.lookupDataSource(DBTransactionImpl.java:1414)
at oracle.jbo.server.DBTransactionImpl2.connectToDataSource(DBTransactionImpl2.java:309)
at oracle.jbo.common.ampool.DefaultConnectionStrategy.connect(DefaultConnectionStrategy.java:203)
at oracle.jbo.server.ApplicationPoolMessageHandler.doPoolConnect(ApplicationPoolMessageHandler.java:553)
at oracle.jbo.server.ApplicationPoolMessageHandler.doPoolMessage(ApplicationPoolMessageHandler.java:409)
at oracle.jbo.server.ApplicationModuleImpl.doPoolMessage(ApplicationModuleImpl.java:8534)
at oracle.jbo.common.ampool.ApplicationPoolImpl.sendPoolMessage(ApplicationPoolImpl.java:4392)
at oracle.jbo.common.ampool.ApplicationPoolImpl.prepareApplicationModule(ApplicationPoolImpl.java:2388)
at oracle.jbo.common.ampool.ApplicationPoolImpl.doCheckout(ApplicationPoolImpl.java:2204)
at oracle.jbo.common.ampool.ApplicationPoolImpl.useApplicationModule(ApplicationPoolImpl.java:3088)
at oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:460)
at oracle.jbo.http.HttpSessionCookieImpl.useApplicationModule(HttpSessionCookieImpl.java:234)
at oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:431)
at oracle.jbo.common.ampool.SessionCookieImpl.useApplicationModule(SessionCookieImpl.java:426)
at oracle.adf.model.bc4j.DCJboDataControl.initializeApplicationModule(DCJboDataControl.java:513)
at oracle.adf.model.bc4j.DCJboDataControl.getApplicationModule(DCJboDataControl.java:856)
..or..
Caused by: javax.naming.NameNotFoundException: Unable to resolve 'jdbc.SomeJndi'. Resolved 'jdbc'; remaining name 'SomeJndi'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:252)
at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:182)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:393)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
..or..
<Utils><buildFacesMessage> ADF: Adding the following JSF error message: Unable to resolve 'jdbc.SomeJndi'. Resolved 'jdbc'
javax.naming.NameNotFoundException: Unable to resolve 'jdbc.SomeJndi'. Resolved 'jdbc'; remaining name 'SomeJndi'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:252)
at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:182)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:214)
at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:393)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
All of these errors occur because of a misconfiguration of a JNDI in one or more of the following locations:

1) the datasource within your WebLogic Server
2) an Application Module's JDBC Data Source within your main ADF application
3) an Application Module's JDBC Data Source within a Bounded Task Flow added to your application via an ADF Library
4) an Application Module's property jbo.server.internal_connection within your main application
5) an Application Module's property jbo.server.internal_connection within a Bounded Task Flow added to your application via an ADF Library

As readers know the JNDI typically takes the form "jdbc/SomeJndi".

Essentially the JNDI for the data source in #1 must be consistent with #2 and #3 otherwise the JNDI lookup fails. In addition if you make use of the jbo.server.internal_connection Application Module property, you'll require a second datasource for #1 that is consistent with that specified in #4 and #5.

This may seem simple, but during a recent development we suffered repeated mistakes where the JNDI was misconfigured causing us large amounts of grief when we thought we had it "sorted". Take the following error message, see if you can spot the issue:

Caused by: javax.naming.NameNotFoundException: Unable to resolve 'jdbc.SomeJndi '. Resolved 'jdbc'; remaining name 'SomeJndi '

Somewhat oddly this error message converts the JNDI such that the forward slashes are replaced with a fullstop. However that's a red herring. Can you see the real error?

If you've looked closely you'll note the JNDI name has an additional space character at the end, something very difficult to visually detect. This resulted in the error above.

For us this particular misconfiguration happened in the worst of places too. Rather than a JNDI used by our main ADF application which would have fallen over straight away, it was used by a secondary ADF Library Bounded Task Flow Application Module's jbo.server.internal_connection setting. As such the application when running under no stress would work fine, but only when the specific Bounded Task Flow was called, and only when the specific Bounded Task Flow was under stress and needed to passivate to the ps_txn table did we see ADF throw the above errors. Before we realized what was going on, a large flapping red herring was that the application would occasionally throw:
JBO-28030: Could not insert row into table PS_TXN, collection id 24,026, persistent id 1" followed by "JBO-27200: JNDI failure. Unable to lookup Data Source at context jdbc/SomeJndi "
...followed by one of the JNDI connections above. But we could see that records were inserted into the ps_txn table regardless of the previous error, and via our own testing, logging into the associated database account specified for the jbo.server.internal_connection, the db user had all the correct database privileges for working with the ps_txn table. Eventually we tracked it back to the misconfigured JNDI, such that the main application with the correct JNDI was happily inserting into PS_TXN, but the secondary Bounded Task Flow JNDI was intermittently causing this issue.

Lesson learned. Don't get your JNDIs wrong.

Thursday 6 May 2010

Configuring Apache JMeter for Apex

A couple weeks ago I blogged how to configure Apache JMeter for testing Oracle's ADF. This week to complete the set, I'll post my findings on stress testing Oracle's Application Express (Apex) with JMeter . Both posts are related to an earlier post on how to record sessions in JMeter that are essential reading to understand what I've specified here.

A Small Caveat

Please note this particular post is the result of my rather limited testing of JMeter with Apex. I'm not an Apex expert, and I haven't used it for over 2 years in any development project. The implication for this post is I might not have discovered absolutely everything that needs to be done to set up JMeter for stress testing Apex in every considerably use case.

If you discover a problem, and hopefully a fix, to assist other readers it would be great if you could post your comments to this blog to assist those next readers please.

Yet Another Small Caveat

For those who read my ADF post, you'll find much of the text in this post similar. I'm mindful I have readers leaping into this post from Google without having read anything earlier, so I'm guessing it's important I give them the same spool. Apologies for repeating myself.

Not a Caveat, But My Thanks

I need to express my thanks to both Penny Cookson and Patrick Wolf with their assistance in getting this post together. Both obviously have a huge amount of experience with Apex and their thoughts and guidance were appreciated.

Introduction

When considering using JMeter for Oracle Application Express applications there are additional JMeter configuration steps required beyond that detailed in the original post. Apex similar to most web applications uses Cookies, and you can use JMeter's HTTP Cookie Manager to correctly handle the cookie. However Apex also makes use of a number of parameters passed as HTTP POST parameters and URL parameters. On running an Apex application you'll often see URL parameters including the session ID, and embedded within the HTTP bodies variables such as p_instance, p_vt01, p_arg_names and more, used by Apex to coordinate state with the browser session. In order for JMeter to simulate multiple user sessions it needs to be correctly configured to handle these too, capturing and carrying the unique values for each session in the load test.

The following post lists the additional configurations required for JMeter beyond those described in the original post. As noted in the original post the easiest way to setup your JMeter Test Plan is to record an existing Apex session through JMeter's HTTP Proxy Server and I haven't bothered to reiterate those instructions here. In turn I've taken no effort to explain the JMeter features we're utilizing to do this; if you want to learn about the relevant JMeter features consult the JMeter User Manual.

These instructions were created against the Apex version 3.2.1.00.10 included with the latest 11gR2 Oracle database release on Windows. Presumably in the future, possibly Apex v4, it will change its HTTP mechanisms, resulting in you having to carefully check this post's instructions against the future Apex version.

JMeter Apex Required Configurations

The following lists the additional objects and their settings required within JMeter. You need only create one of each for each Thread Group but I'll agree there does seem to be a lot of them. The end result will look something like this:


a) HTTP Cookie Manager

Create via Test Plan -> Thread Group -> Right Click -> Add -> Config Element -> HTTP Cookie Manager

Name:HTTP Cookie Manager
Clear cookies each iteration:Selected

In my original JMeter post, you'll see in the comments from Manolis Nikiforakis, he suggests the Cookie policy should be set to "compatible". In my own testing that didn't seem to work, so I used rfc2965 instead. See what works for you.

b) User Defined Variables

Create via Test Plan -> Thread Group -> Right Click -> Add -> Config Element -> User Defined Variables


Name:User Defined Variables Variables
Variable Name:sessionId
Variable Name:p_flow_id
Variable Name:p_flow_step_id
Variable Name:p_instance
Variable Name:p_page_submission_id
Variable Name:p_request
Variable Name:p_md5_checksum
Variable Name:p_arg_values
Variable Name:p_arg_names01...XXX
Variable Name:p_arg_names01name...XXX
Variable Name:p_arg_names01value
Variable Name:success_msg

Above where you see p_arg_names01...XXX and p_arg_names01name...XXX, what I'm implying here is you need to define as many as these as there are submittable fields on your Apex web pages. In the picture you can see I've defined a set of 10. How many do you need to create, well, you need to carefully look at the session requests you've recorded in JDev and identify the maximum number of fields like p_v01, p_t02 etc. If you're not familiar with what I'm describing here, read on and hopefully it'll become more apparent.

c) sessionId Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:sessionId Regular Expression Extractor
Response Field to Check:Body
Reference Name:sessionId
Regular Expression:f?p=([0-9]{1,3}):([0-9]{1,3}):([0-9]{16}):
Template:$3$
Match No.:1
Default Value:n/a

d) p_flow_id Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_flow_id Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_flow_id
Regular Expression:<input type="hidden" name="p_flow_id" value="(.+?)" id="pFlowId" />
Template:$1$
Match No.:1
Default Value:n/a

e) p_flow_step_id Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_flow_step_id Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_flow_step_id
Regular Expression:<input type="hidden" name="p_flow_step_id" value="(.+?)" id="pFlowStepId" />
Template:$1$
Match No.:1
Default Value:n/a

f) p_instance Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_instance Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_instance
Regular Expression:<input type="hidden" name="p_instance" value="(.+?)" id="pInstance" />
Template:$1$
Match No.:1
Default Value:n/a

g) p_page_submission_id Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_page_submission_id Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_page_submission_id
Regular Expression:<input type="hidden" name="p_page_submission_id" value="(.+?)" id="pPageSubmissionId" />
Template:$1$
Match No.:1
Default Value:n/a

h) p_request Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_request Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_request
Regular Expression:<input type="hidden" name="p_request" value="(.+?)" id="pRequest" />
Template:$1$
Match No.:1
Default Value:n/a

It's possible this extractor isn't needed, see why in the following descriptions. However I've included it for completeness.

i) p_md5_checksum Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name: p_md5_checksum Regular Expression Extractor
Response Field to Check:Body
Reference Name: p_md5_checksum
Regular Expression:<input type="hidden" name="p_md5_checksum" value="(.+?)" />
Template:$1$
Match No.:1
Default Value:n/a

It's possible this isn't required. In my mini Apex application I never saw the checksum populated. Potentially it may be in yours so I've included it for completeness here.

j) p_arg_values Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name: p_arg_values Regular Expression Extractor
Response Field to Check:Body
Reference Name: p_arg_values
Regular Expression:<input type="hidden" name="p_arg_values" value="(.+?)" />
Template:$1$
Match No.:1
Default Value:n/a

h) p_arg_names01..XX Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_arg_names01...XX Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_arg_names01..XX
Regular Expression:<input type="hidden" name="p_arg_names" value="(.+?)" /><input type="(hidden|text)" name="(p_[tv]01)"
Template:$1$
Match No.:1
Default Value:n/a

As described in the User Variables section, you'll need as many as these as the maximum amount of fields you have in any of your Apex pages. In the above table the Name and Reference Name should not include ..XX, that's just a notation to mean you need to create many of them. Look to the picture to see exactly what you define for the first.

k) p_arg_names01name..XX Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_arg_names01...XX Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_arg_names01name..XX
Regular Expression:<input type="hidden" name="p_arg_names" value="(.+?)" /><input type="(hidden|text)" name="(p_[tv]01)"
Template:$3$
Match No.:1
Default Value:n/a

Again as per the last extractor, you'll need as many as these as the maximum amount of fields you have in any of your Apex pages. In the above table the Name and Reference Name should not include ..XX, that's just a notation to mean you need to create many of them. Look to the picture to see exactly what you define for the first.

l) p_arg_names01value Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name:p_arg_names01value Regular Expression Extractor
Response Field to Check:Body
Reference Name:p_arg_names01value
Regular Expression:<input type="hidden" name="p_arg_names" value="(.+?)" /><input type="(hidden|text)" name="(p_[tv]01)" value="(.+?)" id="P2_BOOKING_NO" />
Template:$4$
Match No.:1
Default Value:n/a

In your application if you have sequence number fields that are prepopulated from a database sequence number and hidden from the user, you need to include an extractor for each. In this example we're grabbing a hidden P2_BOOKING_NO field.

l) success_msg Regular Expression Extractor

Create via Test Plan -> Thread Group -> Right Click -> Add -> Post Processors -> Regular Expression Extractor


Name: success_msg Regular Expression Extractor
Response Field to Check:Body
Reference Name:success_msg
Regular Expression:success_msg=(Action%20Processed.%2F[A-F0-9]{32,33}%2F)
Template:$1$
Match No.:1
Default Value:n/a

It's possible in this extractor the length of the hex regular expression of 32-33 chars could be to limited.

Recorded HTTP Request Changes

After recording an Apex session in JMeter, and setting up the variables above, you'll note in the recorded HTTP Requests numerous references to the same named variables as HTTP parameters. Yet the recorded HTTP Requests include the parameters' values for the recorded session, which simply won't work when we replay the session as the values will have changed.

It is therefore necessary to identify all locations where the parameters exist in the recorded session HTTP Requests and substitute references to your variables.

a) HTTP Request – Parameters – sessionId

For any HTTP Request that has the parameter "p", where the value looks something like:

102:1: 1438937389458569:::::

The third value must be replaced with

102:1: ${sessionId}:::::


If you see a "p" value that looks something like this:

102:1::::::

...don't modify it.

b) HTTP request – Parameters – for any of the following parameters we need to change their values to the following expressions:

p_flow_id -> ${p_flow_id}
p_flow_step_id -> ${p_flow_step_id}
p_instance -> ${p_instance}
p_page_submission_id -> ${p_page_submission_id}
p_arg_names -> ${p_arg_names}
p_v01...p_vXX -> ${p_arg_names01..XX}
p_t01...p_vXX --> ${p_arg_names01..XX}

...as demonstrated in the following picture:


Then in addition for each p_v01..XX and p_t01..XX fields you'll need to replace the actual parameter names, such that:

p_v01..XX -> ${p_arg_names01name..XX}
p_t01..XX -> ${p_arg_names01name..XX}

...ditto for every parameter name, as demonstrated in the following picture:


You'll note we haven't bothered to do anything with the p_request and p_md5_checksum fields. I'm still not overly convinced we need to, so I've included them in the User Variables and Regular Expression Extractors, but haven't done any more with them at this stage.

c) HTTP request – Parameter – success_msg

For the success_msg parameter, replace its value with ${success_msg}, and ensure Encoding is turned off:


Assertions

Once you've completed the above setup and want to run your load test via JMeter, it is important to see that the test is working correctly. One way to do this is to create a View Results Tree (Test Plan -> Thread Group -> Right Click -> Add -> Listener -> View Results Tree) that allows you to inspect the response of each HTTP Request. If you then see HTTP Request responses in red this indicates a HTTP error code response (!= 200). However it's also necessary to inspect each response even if they are green to see if there's a valid response returned carrying an error message. There is definitely a small knack to differentiating between the different type of failures in an Apex application, which you'll become familiar with on some experience.

In order to save you having to look for the same problems for each test-run, you can create a Response Assertion (Test Plan -> Thread Group -> Add -> Assertions -> Response Assertion) to look for specific errors in the responses. To set this up:

Which Samples to Test:Main Sample Only
Response Field to Test:Text Response
Pattern Matching Rules:Contains
Not:Selected
Patterns to Test #1:The error string you're looking for

Sample JMeter file

Readers can download a sample JMeter JMX file for Apex here with the configurations already setup.

Finishing Comment

As I mentioned much earlier in this post, this post really constitutes my research to date in stress testing Apex with JMeter, and doesn't necessarily cover everything you need to do. Ultimately my goal, like other posts on this blog is to share the spark of inspiration such that you can take the ideas and run with them to form a complete solution yourself. Without a doubt because of the length of this post I'll have a typo or have missed something, so again follow up comments would be appreciated to help the next reader please.

Good luck.