CVS update failures from Hudson

Found out that permission denied errors causing CVS checkout to fail in Hudson was related to Symantec auto-protect running on the build VM. Added security exception to Symantec for D:\hudson\builddir.
See screenshot for exception.

---------------------- CVS checkout failure in Hudson console

$ cvs -Q -z3 -d :pserver:user@cvsserver:/sourceCode co -P -r CVS_TAG -d projectDir -D "Friday, December 9, 2011 9:15:28 PM UTC" projectDir


cvs checkout: cwd=D:\hudson\builddir ,current=D:\hudson\builddir
cvs server: cwd=C:\cvsnt\Temp\cvs-serv1120a ,current=C:\cvsnt\Temp\cvs-serv1120a

cvs [checkout aborted]: cannot create CVS/Entries.Extra.Old for copying: Permission denied

FATAL: CVS failed. exit code=1
------------------------

Oracle SQL Developer Configuration

- Move <sqldeveloper_home>/sqldeveloper/bin/sqldeveloper.conf away so that a new JVM can be selected when SQL developer starts next time.

- All connection configurations are stored in %APPDATA%/SQL Developer/system<sql_dev_ver>/0.jdeveloper.db.connection.<jdev_mod_ver>/connections.xml

- If JDev windows is not visible (mapped outside the screen), then edit MainWindow.x or MainWindow.y property in these files.
%APPDATA%/SQL Developer/system3.0.02.37/o.sqldeveloper.11.1.2.2.37/ide.properties
There could be more than one file in your directory such as
%APPDATA%/SQL Developer/system3.0.04.34/o.sqldeveloper.11.1.2.4.34/ide.properties, so edit the appropriate one.

APEX and Active Directory(what is in bindDN?)

I was setting up Active Directory(AD) authentication for an Oracle APEX application. The settings seemed to be straight forward, but authentication did not succeed. So it was time to fire up ldapsearch from the Oracle db server serving APEX, but found same issues.

After a lot of googling, I did not find any issue being documented for this problem. Then I thought this may not be an issue per say, but how information is perceived by the AD server or how these accounts were set up in AD.

So went further digging on our side ...

I was using samaccountname for bindDN that seemed to work for some application(service) account, but not for my own account. Found some interesting info related to AD or how it was set up in our environment.

- If "samaccountname" to be used for bindDN, then it need to be suffixed with "@domain-name.com" as appropriate.
- One can use "cn" (sn, givenName) as the bindDN if it leads to a unique entry.
- One can use "dn" for bindDN, but this is not user friendly as it is a long one with all the OU and DC info.


Then there were a couple of service accounts that did not seem to have any problem authenticating using samaccountname only, without @domain-name.com appended to it. This one was very confusing initially, but found out that these service accounts were created with no last name(sn), so their first name(givenName) matched their cn and samaccountname. In essence, we thought we were specifying samaccountname for the service accounts, but it was reall their "cn".

So this is how APEX authentication scheme screen finally looked like.

Google search results were hijacked by search.search-tab.com

My wife told me a few days ago that the links from Google search results were hijacked on our home computer. Clicking on links from google keyword search results in Firefox showed unrelated pages, but cutting and pasting the URLs in the address bar seemed to work fine.


She logs in as a restricted Windows user and has been doing Alt+F4 on any ad-window or unrelated pop-ups that beat Fire-fox's block pop-up settings.

Malware bytes's Anti-malware some times showed that it blocked illegal access to an IP address, but it did not happen every time unrelated content showed up. Running Malware scan or Norton did not find anything whether it was a quick scan or full scan. After googling for some time, the problem was found to be related to "keyword.url" configuration property accessed through "about:config" URL. This URL was pointing to "search.search-tab.com" on our home computer. So I reset this property, restarted Firefox to see this problem come up again and the URL was still pointing to search-tab.com.

So I decided to manually clean up this entry found in both user.js and prefs.js under
Documents and Settings/<username>/Application Data/Mozilla/Firefox/Profiles/.default/ directory.

So it seems to be working since then, but I wonder how long?

Disk upgrade

As my old DELL has become slow to boot, started to crank the disk randomly for a long period of time and freezing during this time, I decided to try out an SSD like other people in the group. My laptop was blazing with SSDs, but it lasted for about 3 months as the SSD crashed one day.

So I decided to try out a 7200 RPM disk as the old one was 5400 RPM.

I went ahead and imaged the new disk and also collected manual stats for a normal reboot with no new applications installed. I did not want to use a tool to benchmark before and after as it would tell me the stats, but not how it feels like. So I picked up my phone, paper and pencil and then started the timer.

Here are the stats for a DELL latitude – D620

                                   5400-RPM 7200-RPM

Dell boot appears                   0         0

Windows XP boot screen disappears  27        21
Blue background appears            54        38
Welcome to Windows, login screen   76        54
appears


Entered username and password       0         0
while timer is reset with
left hand.
Custom background picture           6         1
appears                                     
Quick launch bar appears           38        33
Desktop flashes after loading      83        48
all the icons
Disk activity                      183       Stopped.
                                  Still

SQL pitfall ('NOT IN')

It was frustrating recently to see that the following simple SQLs behave fundamentally different though one result was supposed to be the negative of the other.

-- Lists emloyees present in the tmp table.
select * from empl empl
where empl.empl_id in (select empl_id from tmpTable);

-- Expected to list the employees that are not present in the tmp table
-- Very similar to the above query, but using 'not in' construct.
select * from empl empl
where empl.empl_id not in (select empl_id from tmpTable);

No results were returned from this query though a number of records were expected to be returned.

After digging into the basics and spending quite a bit of time googling, a record with null emloyee id was found in the tmpTable, which originated from the CSV source file used to populate this table.

So I put in a filter 'where empl_id is not null' for second query (based on 'not in') alone. Realized that I should have used 'not exists', and would have avoided this pitfall.

Moving BPEL Data and Files to a test environment - 2

We did another round of prod to test move of data and files, a few days ago, but found out this time that processes with wait activities did not wake up even after of expiry of the time.

After refreshing alarm table a few times in vain and  frustrated digging attempts here and there, found out that the column orabpel.work_item.cluster_node_id had the IP address and a port number of the production cluster nodes. I guess these entries prevented these processes from waking up in the test environment as the test server IP was different from production servers.

So this column was nulled, then restarted oc4j_soa and then all of those pending processes woke up to move further.

Moving BPEL Data and Files to a test environment - 1

We had to recently capture a snapshot of BPEL metadata from production to be put in an test environment where some of the long running processes were continued and observed in the new test environment. So we started with a consistent copy of production BPEL database and then copied all BPEL deployment files from $OC4J_HOME/bpel/domains/default/tmp directory to the new environment where OC4J was running.

Then we had to ensure that the new test environment was isolated so that continuing process instances in this test environment would not interact with production systems. Unfortunately our production network was not isolated from the test servers. In other words all production servers were resolvable from this test servers.

So we had to come up with some tweaks on the server that was hosting OC4J application server to prevent the new instance from responding to actual clients.

- Production ports for OC4J were restricted only from the production Web servers.
- Redirected all production partner link hosts to 127.0.0.1 in the Windows hosts file of the OC4J test server.
- Redirected all production cluster and node hostsnames for OC4J to 127.0.0.1 as well in the Windows hosts file of the OC4J test server.

This did it for us as the client base for BPEL processes were small, so we could do an inventory of all client machines and then route them to 127.0.0.1 in windows hosts file to prevent the test instance talking to production clients. It could have been worse if the client base was wide and they made async calls.

OC4J and support for 64bit JVM

OC4J supports 32bit JVMs only on Windows x64 platforms. OC4J, starting from 10.1.3.4, supports using an external JVM for an instance.

But no where it to be found, in any of the documents, about not using a 64bit JVM for a newly created OC4J(custom) instance.

The ability to plug in a JVM may pave the way for using a 64bit JVM in a 32bit install, if that instance runs pure JAVA applications (no JNI based code). So we added necessary data elements to opmn.xml to start an OC4J instance using a 64bit JVM.
Everything is looking good since then and all applications (JAVA only) are seen to be working ok on this instance. This instance also shows up in the enterprise manager console, but seemed to take up a little more memory than a 32bit version would do at start up or run time. This could be related to how addresses are aligned in a 64bit executable.

We have it running for a few weeks in dev now (home and oc4j_soa in 32bit JVM and oc4j_apps in 64bit JVM) and did not see any issues so far. I will keep updating this blog if I come across any issues in the future.

DB Adapter configurations not recognized after 10.1.3.5 migration

Oracle DB adapter configurations (connector configurations), though present in J2EE_HOME/application-deployments/default/DbAdapter/oc4j-ra.xml not recognized after upgrading to OC4J 10.1.3.5 from 10.1.3.4 (mlr#10).

The issue was seen to be related to the presence "usesSkipLocking" attribute for a connector definition. Removing this attribute (XPath exp: ...config-property/@name[.='usesSkipLocking']) from definitions in oc4j-ra.xml and then restarting the OC4J container seemed to bring them back.