| Summary: | "javax.naming.NameNotFoundException: InquiryService not bound" during server shutdown. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 4 | Reporter: | Pavel Macik <pmacik> | ||||
| Component: | JBossESB | Assignee: | Kevin Conner <kevin.conner> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 4.3 CP02 | CC: | dlesage | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 4.3 CP04 ER1 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | http://jira.jboss.org/jira/browse/SOA-1546 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: |
RHEL5-x86_64, Sun JDK 1.6.0_13-x86_64
|
|||||
| Last Closed: | 2010-03-24 09:10:01 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Deadline: | 2010-03-08 | ||||||
| Attachments: |
|
||||||
|
Description
Pavel Macik
2009-10-23 09:50:22 UTC
Attached whole server log Attachment: Added: server.log.zip I can't see the exception neither in the EAP nor in the ESB nor in the AS... just in SOA-P. Juddi code has changed since ER1 removing SOA 5 fix version as this jisra is no longer applicable Help Desk Ticket Reference: Added: https://enterprise.redhat.com/issue-tracker/453363 I could reproduce this error by starting SOA-P 4.3 CP02 in a clustered profile and the -b <IP> switch: ./bin/run.sh -c production -b x.x.x.x If I start the same instance with -b 0.0.0.0, I get a different error message at server shutdown: ERROR [MessagingXAResourceWrapper] ********************************Failed to connect to server javax.naming.NameNotFoundException: DefaultJMSProvider not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:581) at org.jnp.server.NamingServer.getBinding(NamingServer.java:589) at org.jnp.server.NamingServer.getObject(NamingServer.java:595) at org.jnp.server.NamingServer.lookup(NamingServer.java:342) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:667) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627) at javax.naming.InitialContext.lookup(InitialContext.java:409) Suggested for SOA 4.3 CP03, needs approval. Approved for SOA 4.3 CP03, if done by due date. I have tried without success to reproduce this issue and the only theory I can come up with is a discrepancy between the juddi codebase responsible for registering the entries in JNDI and our MBean, which eventually unbinds them. The juddi codebase (and our current configuration) forces the JNDI binding to take place over RMI, whereas the unbind in our MBean uses the default InitialContext. One possible scenario could be that the RMI lookup is failing, forcing the fallback to the discovery mechanism. In any case the juddi JNDI accesses should be using the local server, rather than over RMI, so I will make that change. Link: Added: This issue depends JBESB-3202 The binding now takes place using the local JNDI server, hopefully addressing this issue. The issue raised by Martin is not the same as this one. If this reappears, please create a new issue and link it to this one. Updated in ESB codebase, will be in next merge. The draft text for the Resolved Issues section of the Release Notes states: https://jira.jboss.org/jira/browse/JBESB-3202 Whilst the server was shutting down, a javax.naming.NameNotFoundException: InquiryService not bound exception could occur. This appears to have been caused by a discrepancy between the jUDDI codebase responsible for registering the entries in JNDI and the MBean which eventually unbinds them. This is because the binding was occurring over RMI whilst the MBean was using the default InitialContext. The code has now been changed so that JNDI accesses no longer occur over RMI. Rather, the local server is used. Verified in ER1 |