NullPointerException during to Webshpere MQ connection from OSB - nullpointerexception

From OSB project I connect to IBM Websphere MQ in BINDING MODE. Sending message asynchronously from the Business Service to MQ queue is working fine but I keep getting a NPE.
Could someone please tell me what I am doing wrong :) and I advice? I am new to OSB and MQ. The error is below:
<AdminServer> <[ACTIVE] ExecuteThread: '23' for queue: 'weblogic.kernel.Default (self-tuning)'>
<<WLS Kernel>> <> <d4c01266a9822b8f:-5e045fa4:154e15afad0:-8000-000000000000222d> <1464087403232> <BEA-000802> <ExecuteRequest failed
java.lang.NullPointerException.
java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:209)
at java.util.concurrent.ConcurrentHashMap.containsKey(ConcurrentHashMap.java:836)
at com.bea.wli.sb.resources.mqconnection.MQConnectionFacade.getMQConnectionContext(MQConnectionFacade.java:70)
at com.bea.wli.sb.transports.mq.MQTransportTimerListener.timerExpired(MQTransportTimerListener.java:222)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:284)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:550)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:263)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

A java.lang.NullPointerException is being thrown because a null object has been passed into the containsKey(Object) method on a ConcurrentHashMap. See the Javadoc for this:
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html#containsKey(java.lang.Object)
You need to work out why the code in com.bea.wli.sb.resources.mqconnection.MQConnectionFacade.getMQConnectionContext(MQConnectionFacade.java:70) is trying to lookup an object using a null key. If this is code belongs to Oracle, you might need to engage their Support Teams.

Related

Web logic thread dump analysis : HttpSession is invalid

Hi I am very new to thread dump analysis so please excuse. There was an increase in WL queue, while trying to analyze I got this below error, several(more than 1000) times.
Can anybody help me what is the issue with the below one, and how does sessions got invalidated? Is this a potential issue?
<[ACTIVE] ExecuteThread: '173' for queue: 'weblogic.kernel.Default (self-tuning)'> <guest> <> <> <1472479201177> <BEA-100025> <An unexpected error occurred in HTTP session timeout callback while deleting sessions.
java.lang.IllegalStateException: HttpSession is invalid
at weblogic.servlet.internal.session.SessionData.getInternalAttribute(SessionData.java:790)
at weblogic.servlet.internal.session.SessionData.getInternalAttribute(SessionData.java:785)
at weblogic.servlet.internal.session.SessionContext.invalidateSession(SessionContext.java:1067)
at weblogic.servlet.internal.session.SessionContext.access$400(SessionContext.java:45)
at weblogic.servlet.internal.session.SessionContext$SessionInvalidator.cleanupExpiredSessions(SessionContext.java:1001)
at weblogic.servlet.internal.session.SessionContext$SessionInvalidator$1.run(SessionContext.java:903)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.session.SessionContext$SessionInvalidator.timerExpired(SessionContext.java:897)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:284)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:550)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:263)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

Weblogic server log fills up with <BEA-010213>

My Weblogic server log fills up with this error message:
####<Mar 2, 2015 11:38:57 AM MST> <Info> <EJB> <max75demo> <MAXIMOSERVER> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1425321537312> <BEA-010213> <Message-Driven EJB: JMSContQueueProcessor-1's transaction was rolled back. The transaction details are: Xid=BEA1-73C4DAA3AC1F8569980C(21198065),Status=Rolled back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException: setRollbackOnly called on transaction],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=60,XAServerResourceInfo[WLStore_mydomain_cqinstore]=(ServerResourceInfo[WLStore_mydomain_cqinstore]=(state=rolledback,assigned=MAXIMOSERVER),xar=WLStore_mydomain_cqinstore21478888,re-Registered
= false),SCInfo[mydomain+MAXIMOSERVER]=(state=rolledback),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=MAXIMOSERVER+10.0.0.11:80+mydomain+t3+, XAResources={WLStore_mydomain_sqinstore, WLStore_mydomain_sqoutstore, WSATGatewayRM_MAXIMOSERVER_mydomain, WLStore_mydomain_cqinstore},NonXAResources={})],CoordinatorURL=MAXIMOSERVER+10.0.0.11:80+mydomain+t3+).>
These logs consume disk space at 5MB/s, causing my small drive to fill up quickly. The only recent change out of the ordinary was that I synced the machine's time with a time server and changed the time zone. I have since cleared out the tmp folder and have restarted the server but to no avail. I'm running Weblogic 10.3.3.0.
Is there something I can do to prevent these errors from occurring?
Thanks!
Thanks for the tip.
In my case, a co-worker had made some changes to an enterprise product on the host I was using (without informing me) which was likely causing these error messages, since the change involved JMS queues. Had nothing to do with the time change.

Java OOM: no heapdump created

I'm getting OOM of memory issue on a long running application (3~5 hours) with the following symptoms
-XX:+HeapDumpOnOutOfMemoryError produce an empty dump
http://bugs.java.com/view_bug.do?bug_id=6784422
Exception in thread "[STANDBY] ExecuteThread: '21' for queue:
'weblogic.kernel.Default (self-tuning)'" java.lang.OutOfMemoryError:
getNewTla
Is there any other JVM options I can add to find out the exact cause I have the above symptoms. The application owner is refuse to allow me like increase xmx xns xms or anything with exception of collecting more data.
jrockit-jdk1.6.0
Since you are using jrockit, you need to bump up the tla
-XXtlaSize:min=10k,preferred=256k

Error with Weblogic 10.x while deploying

I am receiving an error while I try to connect my local environment to a Test DB. Deployment of the ear file fails.
Here's the exception stack trace.
####<Sep 5, 2013 5:22:22 PM IST> <Info> <Deployer> <H1-DDM67BS> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1378381942855> <BEA-149060> <Module nemo of application NeMo successfully transitioned from STATE_PREPARED to STATE_ADMIN on server AdminServer.>
####<Sep 5, 2013 5:22:24 PM IST> <Warning> <JMSPool> <H1-DDM67BS> <AdminServer> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1378381944212> <BEA-169808> <There was an error while making the initial connection to the JMS resource named jms/statisticsFactory from the EJB "JMSWriter" inside application "NeMo". The server will attempt the connection again later. The error was javax.jms.JMSException: [JMSPool:169803]JNDI lookup of the JMS connection factory jms/statisticsFactory failed: javax.naming.NameNotFoundException: While trying to lookup 'jms.statisticsFactory' didn't find subcontext 'jms'. Resolved ''; remaining name 'jms/statisticsFactory'>
####<Sep 5, 2013 5:22:26 PM IST> <Info> <Kodo> <H1-DDM67BS> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-00003CA049AA50DAD185> <> <1378381946428> <BEA-2004002> <Starting BEA Kodo 4.1.3.1>
####<Sep 5, 2013 5:22:26 PM IST> <Info> <Kodo JDBC> <H1-DDM67BS> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-00003CA049AA50DAD185> <> <1378381946474> <BEA-2002382> <[JDBC] Using dictionary class "com.bmw.nemo.business.util.MyOracleDictionary".>
####<Sep 5, 2013 5:22:26 PM IST> <Info> <Kodo JDBC> <H1-DDM67BS> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-00003CA049AA50DAD185> <> <1378381946584> <BEA-2002360> <[JDBC] OpenJPA is now connecting to the database in order to figure out what JDBC driver you are using, as OpenJPA must alter its behavior for this database depending on the driver vendor. To avoid this connection, set the DriverVendor value in your org.apache.openjpa.jdbc.DBDictionary configuration property to one of the following values: oracle, oracle92 (for the 9.2 driver), datadirect, datadirect61 (for driver versions <= 3.1), other For example: org.apache.openjpa.jdbc.DBDictionary: oracle(DriverVendor=oracle92)>
####<Sep 5, 2013 5:22:28 PM IST> <Warning> <Kodo> <H1-DDM67BS> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-00003CA049AA50DAD185> <> <1378381948783> <BEA-2000012> <[MetaData] Found duplicate query "XXXX.ProjektByWerkJoin" in "class XXXX.ProjektBE". Ignoring.>
####<Sep 5, 2013 5:22:59 PM IST> <Info> <EJB> <H1-DDM67BS> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-00003CA049AA50DAD185> <> <1378381979251> <BEA-010051> <EJB Exception occurred during invocation from home: weblogic.ejb.container.internal.StatelessEJBHomeImpl#239c1e7 threw exception: <1.0.0.1.1 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 32 seconds
BEA1-00003CA049AA50DAD185]'. No further JDBC access is allowed within this transaction.
<1.0.0.1.1 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 32 seconds
BEA1-00003CA049AA50DAD185]'. No further JDBC access is allowed within this transaction.
at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:3849)
at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3813)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
at org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:155)
at org.apache.openjpa.lib.rop.EagerResultList.<init>(EagerResultList.java:40)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1219)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:987)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:796)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:766)
at kodo.kernel.KodoQuery.execute(KodoQuery.java:43)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:762)
at kodo.kernel.KodoQuery.execute(KodoQuery.java:39)
at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:230)
at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
===============
I have tried all sorts of setting on JTA by increasing the timeouts etc on weblogic console, didn't work.
I have dumped the whole data on my local oracle DB and then connected it works perfectly but it's a tedious job again and again to take the dump from remote DB and dump it on my local DB.
I am not sure why it's not working when I connect to remote DB but locally it works with the same weblogic settings.
Please share your opinions.
-Vishal Nadikudi

Weblogic WorkManager policies across war to ejb-jar

I have a servlet that is employing the defaultWM for Weblogic. This servlet in turn calls an ejb. This ejb is associated with a different WM ( WM_EJB ). What I'd like to know, when a thread comes in to be processed via the servlet, does the servlet use the defaultWM and then the carry the same WM context to the ejb call? or is there a switch?
i.e.
External request to ServletA -- ServletA is configured with DefaultWM
ServletA processes request and call EJB.helloWorld()
EJB.helloWOrld() is configured with WM_EJB workmanager
Does the entire process use the DefaultWM or does it switch on the call to EJB.helloWorld()
My apologies if this was answered somewhere else, i couldn't find an answer to WM flow.
I've been doing some investigations on this and my response is that Weblogic *will switch over from DefaultWM to the component's WorkManager say EJB_WM* if one is defined.
Remember the execute thread remains the same - so once a request has come in, the same thread will execute the servlet, and then the EJB.
In my sample app, I'm firing 50 concurrent calls to an index.jsp, whereas in the weblogic-ejb-jar.xml, I've defined this constraint for the EJB alone
<work-manager>
<name>WorkManagerA</name>
<max-threads-constraint>
<name>MyMaxThreadCount</name>
<count>1</count>
</max-threads-constraint>
</work-manager>
I can see the logs showing 2 parallel calls in different threads 6 and 8 within index.jsp
INDEX.JSP - Current ThreadName Is: [ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'
INDEX.JSP - Current ThreadName Is: [ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'
Now some more log statements
Calling EJB from index.jsp 1317985368088[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'
Start EJB 1317985368088[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'
end EJB 1317985368088[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'
Calling EJB from index.jsp 1317985368088[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'
Start EJB 1317985368104[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'
end EJB 1317985368104[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'
As the timestamps (System.currentTimeMillis()) show, index.jsp has been called at the same time 1317985368088 from Threads 6 and 8, however the
System.out.println statements called "Start EJB" and "end EJB" have a different timestamp for Threads 6 and 8. These are from within the EJB.
This shows the EJB WorkManager is doing it's task of constraining the Parallel Thread Count to only 1 at a time