ERROR - Error loading JNDI context JndiContext-11.

we are on OD 5.6 W2k.
i get this in server_eventreporting.log

at first i thought java wasnt installed, but i did make sure it is installed.
can anybody tell what causes this be thrown??]
thank you.

2006-11-06 10:53:29,188 [Thread-3] WARN - Skipping JNDI context JndiContext-11 and all its subordinate objects.
2006-11-06 10:58:29,178 [Thread-3] ERROR - Error loading JNDI context JndiContext-11.
2006-11-06 10:58:29,178 [Thread-3] INFO - Reason:
javax.naming.NamingException: JndiServer. Root exception is
java.rmi.NotBoundException: JndiServer
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:240)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:349)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:79)
at org.exolab.jms.jndi.rmi.RmiJndiInitialContextFactory.getInitialContext(Unknown Source)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:660)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:241)
at javax.naming.InitialContext.init(InitialContext.java:217)
at javax.naming.InitialContext.(InitialContext.java:173)
at com.interwoven.report100.TEventReportingManager.initJndiContext(TEventReportingManager.java:746)
at com.interwoven.report100.TEventReportingManager.initJndiContexts(TEventReportingManager.java:786)
at com.interwoven.report100.TEventReportingManager.access$1300(TEventReportingManager.java:108)
at com.interwoven.report100.TEventReportingManager$TRestartTask.run(TEventReportingManager.java:1872)
at java.util.TimerThread.mainLoop(Timer.java:430)
at java.util.TimerThread.run(Timer.java:380)
2006-11-06 10:58:29,178 [Thread-3] WARN - Skipping JNDI context JndiContext-11 and all its subordinate objects.

Find more posts tagged with

Comments

Nicholas

Just make sure if you enabled evert subsystem (es_enable=true) in [event_subsystem] section in iw.cfg

Hope this will help you

Thanks Nicholas

SBR

FYI

This error indicates that the OpenDeploy Administrative Server cannot connect to an OpenDeploy node to receive reporting events. It can occur if the OpenDeploy Administrative Server is started before the OpenDeploy node(s) or when the OpenDeploy node(s) are stopped before the Administrative Server.

By default, the Administrative Server will try to reconnect every five minutes. If this doesn't resolve the issue, you should stop OpenDeploy Administrative Server and then stop the managed nodes. Restart the managed nodes and then restart the Administrative Server.

CRB

this is all i have in iwopenapi/iw.cfg
---------
[locations]
iwroles=D:/Interwoven/OpenAPI/iwopenapi/roles
entities=D:/Interwoven/OpenAPI/iwopenapi/entities
---------------------------
should i enable it in this iw.cfg?

i am not sure which nodes you are takling about:
this is how our deployment set up:

A-TS 5.5.2/ OD 5.6 sender *****--> **** D-
****************************************OD 5.6
B-TS 5.5.2/ OD 5.6 sender *****--> ***ADMIN*******-->E- OD 5.6 Receivers
*****************************************/Sender
C- OD 5.6 sender **************-->

so server D is where igot the error from, since it has the OD admin, do you mean it couldnt connect to the Sender in the same box? or also to the ones in the other boxes?

Migrateduser

we are on OD 5.6 W2k.
i get this in server_eventreporting.log

at first i thought java wasnt installed, but i did make sure it is installed.
can anybody tell what causes this be thrown??]
thank you.

2006-11-06 10:53:29,188 [Thread-3] WARN - Skipping JNDI context JndiContext-11 and all its subordinate objects.
2006-11-06 10:58:29,178 [Thread-3] ERROR - Error loading JNDI context JndiContext-11.
2006-11-06 10:58:29,178 [Thread-3] INFO - Reason:
javax.naming.NamingException: JndiServer. Root exception is
java.rmi.NotBoundException: JndiServer
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:240)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:349)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:79)
at org.exolab.jms.jndi.rmi.RmiJndiInitialContextFactory.getInitialContext(Unknown Source)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:660)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:241)
at javax.naming.InitialContext.init(InitialContext.java:217)
at javax.naming.InitialContext.(InitialContext.java:173)
at com.interwoven.report100.TEventReportingManager.initJndiContext(TEventReportingManager.java:746)
at com.interwoven.report100.TEventReportingManager.initJndiContexts(TEventReportingManager.java:786)
at com.interwoven.report100.TEventReportingManager.access$1300(TEventReportingManager.java:108)
at com.interwoven.report100.TEventReportingManager$TRestartTask.run(TEventReportingManager.java:1872)
at java.util.TimerThread.mainLoop(Timer.java:430)
at java.util.TimerThread.run(Timer.java:380)
2006-11-06 10:58:29,178 [Thread-3] WARN - Skipping JNDI context JndiContext-11 and all its subordinate objects.

This message is thrown when a connection cannot be made to the internal JMS subsystem. For the AdminServer, the most common cause of this message is that the associated OD "node" (Base or Reciever) that it is subscribing to is not up and running. In that case it is a harmless warning message.

The filename "server_eventreporting.log" leads me to believe that this is occuring on the OD Base/Receiver side though. If that is correct, that means that there is a problem with the JMS subsystem. Unfortunately, that probably means that it's database is corrupted and it fails to start properly.

The quick version of the way to correct that problem is to stop AdminServer and OD. Delete the files "/db/openjms.db.*". Then run the command: "/lib/dbtool -create -config /etc/jmsconfig.xml". This will correct the problem, but you will loose and undelivered reporting event messages. Though that may be part of the problem too.

If you are going to use the Event Reporting feature (which is ON for Base servers by default) then you need to keep the AdminServer that subscribes to it's messages up all the time too. That is not an absolute guarantee that this cannot happen again, but it helps out a lot.

Another suggestion would be to upgrade to the latest patch of OD6.1.0 or wait for OD6.1.1 where some signifigant improvements have been made in terms of the reliability of the reporting infrastructure.

Thanks,
Mike

CRB

the issue is that we are not using any datadeploy, and we dont use the reporting logs unless somehting fail or an issue. and i dont really know how things are configured here. i did find few files named "rmi_jms_external_jndi" and "create_db2.sql" and many more under ODNG/openjms/config .. but i wasnt sure if those files were made by somebody here or by Interwoven installation process...

John742

I do not remember how 5.6 worked with openjms but be careful with the /openjms directory the newer version of OD (and perhaps 5.6 do not remember) pass a config file to openjms when it is invoked so it does not use any of those default configs that are rolled into the OOTB opensource openjms app. od-home/etc/jmsconfig.xml is the place where you would set the invocation params in the newer versions . your error appears comes from jndi not listening on the assigned port, but that should have been invoked by openjms. do you have your od events going to a DB? IF so do you see actvity in it? I would check the to see if anything is bound to the JNDI port or just restart the server to release the port to see of the error goes away.

CRB

well we dont deploy anything to any database, but we have datadeploy installed. so maybe it is not listenning to the right port because we never configured it since we dont deploy any database... we onyl deploy our static content to the our production servers... i saw this error in log files from 2005/2004... and it never affected the deployment jobs.

John742

Understand, but I am talking about Open Deploy event persistance. What r u using to persist? Better yet, was there any changes to how Open Deploy persists events after install. Someone help me out here that has 5.6 installed. Does odbase.xml have the eventreporting node ? Look in odbase for event reporting enabled = true. If you do not use it turn it off, otherwise I would suggest an RDBMS to persist this stuff.

CRB

yes it is enable, and i guess we are not using it...

enabled="yes"
cfgPath="D:\Interwoven\OpenDeployNG\etc\eventReportingConfig.xml"
/>
would this affect our deployment process if we turn it off?

the reason i am only 99% sure that we are not using it, because i just started with this organization, and so far i dont see it used anywhere because i maintain OD here... but there are always suprises out there...

John742

Unless you are using the reports for something(wf,external tasks, metrics, easy lookups for admins). turn it off and do a iwodserverreset to see if this is what is causing your issue. you can always reenable it afterwards until you are sure you do not need it. Also I would check your OD receivers for this settings you almost never need it enabled on the receiver side and it takes up resources and disk space.

CRB

sounds great thank you... Smiley Happy

. in the next few weeks, we are moving to OD 5.6 SP1 to OD 6.1 and from TS 5.5.2 SP5 to TS 6.5 SP2 on w2003. so i will make sure all the configs are clear in the new servers.

Migrateduser

yes it is enable, and i guess we are not using it...

enabled="yes"
cfgPath="D:\Interwoven\OpenDeployNG\etc\eventReportingConfig.xml"
/>
would this affect our deployment process if we turn it off?

the reason i am only 99% sure that we are not using it, because i just started with this organization, and so far i dont see it used anywhere because i maintain OD here... but there are always suprises out there...

No, it will not affect the deployment process at all if you turn it off. In fact, it can only spped things up a bit. The only thing that you will "lose" is the reports of deployments in the OD AdminServer, but it doesn't sound like you're using that feature. If that is the case, here is how you can disable event reporting.

1) Edit the file /odadmin/config/adminEventReportingConfig.xml. Near the end you will see an element named "odnode" that refers back to the ODBase server on this machine. Comment it out. (Optional check and clean the AdminServer logs because one of them will have a bunch of the ERROR - Error loading JNDI context JndiContext-11 messages). Restart AdminServer.

2) Stop ODBase. Edit /etc/odbase.xml. In the "eventReporting" element, change the "enabled" attribute to "no".

3) Delete the files /db/openjms.db.*

4) Run the command /lib/dbtool{.bat|.sh} -create -config /etc/eventReportingConfig.xml (NOTE: dbtool is a script and you may have to add .sh to the command name on Unix machines, I don't remember off the top of my head).

That should clean up everything for you!

Thanks,
Mike