run failed with was/db2

Product Support > SPECvirt_sc2013

(1/2) > >>

sorcier:
Hi all,
I deployed the SPECjApp2004 environment with WebSphere and DB2 based on the result files of others, I can successfully ping the database in the web console of WebSphere now. But after executing the run script, an error is reported as follows:

......
Messages from: 192.168.0.18:1010
-> 2019-11-22 03:53:03:731 specwebclient: setting tile ID to 0
-> 2019-11-22 03:53:03:752 Looking up polling host: webserver:8001

Messages from: 192.168.0.18:1091
-> 2019-11-22 03:53:19:564 Starting Agents
-> ---------------//client1:2098/Controller
-> Calling switchLog as master
-> url[0] is : http://specemulator:9081/Emulator/EmulatorServlet?cmd=switchlog
-> url[0] is : http://specemulator:9081/Emulator/EmulatorServlet?cmd=switchlog
-> url[1] is : http://specdelivery:9080/Supplier/DeliveryServlet?cmd=switchlog
-> calling driver.waitMatch(0)...
-> 2019-11-22 03:53:34:622 waiting for: waiting2ramp
-> RunID for this run is : 45
-> Output directory for this run is : /opt/SPECjAppServer2004/output/45
-> loadFactor=5
-> changeRate=30
-> burstyCurve from run.properties=37,72,61,87,132,77,0,49,137,93,187,103,174,138,200,173,153,107,225,44,36,44,48,68,138,125,116,88,38,50
-> scaleFactor=1.0
-> Curve avg txRate = 100.0
-> maxTxRate=225
-> tileNumber=0
-> Will run in bursty mode after rampup/warmup phases. Starting at burstPoint:0
-> WarmUp style = 0 (0=linear only, 1=burstycurve, 2=zigzag)
-> Phase one of warm up (start of transaction activity) will increase IR from 0 to 100 linearly, over 900 seconds.
-> Steady-State IR transition stepRate(ms)=40000
-> Burst Curve StartPoint Tile Multiplier=7
-> smoothFactor=1
-> Using default timeSkewTolerance value: 3
-> Exception encountered in auditor.validateInitialValues(). Aborting.
-> java.rmi.RemoteException: InitialContext failed. javax.naming.NoInitialContextException: Failed to create InitialContext using factory specified in hashtable [Root exception is java.lang.NullPointerException]

Can someone help me or give me some advice？
Thanks.

abond:
Hey Sorcier,

Have you tried running the curl commands to validate the appserver/dbserver setup and communication? You can find them in the section "Appserver/Dbserver" of the Technical Support document.

https://spec.org/virt_sc2013/docs/SPECvirt_TechnicalSupport.html#Appserver

Andy

sorcier:
hey，Andy
The curl commands and results are as follows：

[root@client1 ~]# curl http://specdelivery:9080/Supplier/DeliveryServlet?cmd=switchlog
200 OK
[root@client1 ~]# curl http://specemulator:9081/Emulator/EmulatorServlet?cmd=switchlog
200 OK
[root@client1 ~]# curl http://specdelivery:9080/SPECjAppServer/app?action=atomicityTests
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META http-equiv="Content-Style-Type" content="text/css">
<TITLE>Atomicity Tests</TITLE>
</HEAD>
<BODY bgcolor="#ffffff" link="#000099" vlink="#000099">

<TABLE width="645" align="left">
<UL>

SPECjAppServer2004 Transaction Atomicity Test
 
</UL>
 

<UL>
Definition: The System Under Test must guarantee that all Transactions are atomic; the system will either perform all individual operations on the data, or will assure that no partially-completed operations leave any effects on the data. The tests that were executed with their results below were used to determine if the System Under Test you are operating on meets all the transactional atomicity requirements. If any of the tests have a result of "FAILED" your system is not set up to ensure transaction atomicity
</UL>
<UL>
Test 1: This test checks to see if the proper transaction atomicity levels are being upheld in transactions associated with the benchmark. This test case drives placing an order for immediate insertion into the dealerships inventory. An exception is raised after placing the order and while adding the inventory to the dealer▒s inventory table. This should cause the transaction changes to be removed from the database and all other items returned to how they existed before the transaction took place. This test case has three steps which are as follows to verify atomicity

1.) Query database to check how many inventory items the dealership has, the dealerships account balance, and the number of orders which have been placed for the dealer inside of the dealer domain. These numbers are the initial metrics that the final test cases should line up with after rolling back the transaction.

2.) Drives the above transaction which causes a transaction rollback exception to occur.

3.) Query database to check how many inventory items the dealership has, the dealerships account balance, and the number of orders which have been placed for the dealer inside of the dealer domain. These numbers should equal those in step 1) for the test case to be successful and the transaction to have been atomic.


<LI>Atomicity Test One: PASSED</LI> 


Test 2: This test transaction simply tests that the application server is working properly and that it is able to insert an order as in Atomicity test 1 but without causing the exception and have it show up in the database.
<LI>Atomicity Test Two: PASSED</LI> 


Test 3: This test checks to see if the proper transaction atomicity levels are being upheld in transaction associated with the benchmark and specifically the messaging subsystem in this test case. This test case drives placing a order which contains a large order and an item to be insert immediately into the dealerships inventory. An exception is raised after placing the order and while adding the inventory to the dealer▒s inventory table. This should cause the transaction changes to be removed from the database, messages removed from queue and all other items returned to how they existed before the transaction took place. This test case has three steps which are as follows to verify atomicity.

1.) Query database to check how many inventory items the dealership has, the dealerships account balance, and the number of orders which have been placed for the dealer inside of the dealer domain. Also the large order table is queried to check how many large orders exist in the database before we drive the transaction. These numbers are the initial metrics that the final test cases should line up with after rolling back the transaction.

2.) Drives the above listed transaction which causes a transaction rollback exception to occur.

3.) Query database to check how many inventory items the dealership has, the dealerships account balance, and the number of orders which have been placed for the dealer inside of the dealer domain. Also query the large order table to check how many large orders there are in the table. These numbers should equal those in step 1) for the test case to be successful and the transaction to have been atomic.

<LI>Atomicity Test Three: FAILED</LI> 

</UL>
</TABLE>
</BODY>

I see that test3 returns a "FAILED", so the atomicity test of the database failed.
Next，i think i should modify the transaction atomicity level, am I right ？ Or is there anything else I haven't noticed?

Thanks

abond:
Hey sorcier,

Were you able to get that third atomicity tests to pass? That test failing doesn't necessarily mean it is the cause of the original error you reported, but being able to verify that the database is built and functions correctly is a key step to debugging your environment.

Andy

Frederick458:
A possible root cause of this error message is that the system has an incompatible VC++ 2008 redistributable package already installed, prior to installation of the Db2 database product.

Navigation

[0] Message Index

[#] Next page

Go to full version