You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Ole Ersoy (JIRA)" <ji...@apache.org> on 2007/05/31 21:17:16 UTC
[jira] Commented: (DIRSERVER-950) Server Left in Unstable State
[ https://issues.apache.org/jira/browse/DIRSERVER-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500455 ]
Ole Ersoy commented on DIRSERVER-950:
-------------------------------------
This is only circumstantial material
that might be helpful. After reinstalling
ADS, it crashes immediately when running
apacheds start. When running with
apacheds debug it also crashes,
and here is the exception (This is with
ADS reporting a clean shutdown after
running apacheds stop):
[13:59:36] WARN [org.apache.directory.server.core.DefaultDirectoryService] - You didn't change the admin password of directory service instance 'default'. Please update the admin password as soon as possible to prevent a possible security breach.
[13:59:36] ERROR [org.apache.directory.server.jndi.ServerContextFactory] - Failed to bind an LDAP service (10389) to the service registry.
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at org.apache.mina.transport.socket.nio.SocketAcceptor.registerNew(SocketAcceptor.java:429)
at org.apache.mina.transport.socket.nio.SocketAcceptor.access$900(SocketAcceptor.java:52)
at org.apache.mina.transport.socket.nio.SocketAcceptor$Worker.run(SocketAcceptor.java:258)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:43)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:619)
[13:59:36] ERROR [org.apache.directory.daemon.Bootstrapper] - Failed on org.apache.directory.server.Service.init(InstallationLayout, String[])
org.apache.directory.shared.ldap.exception.LdapConfigurationException: Failed to bind an LDAP service (10389) to the service registry. [Root exception is java.net.BindException: Address already in use]
at org.apache.directory.server.jndi.ServerContextFactory.startLDAP0(ServerContextFactory.java:489)
at org.apache.directory.server.jndi.ServerContextFactory.startLDAP(ServerContextFactory.java:403)
at org.apache.directory.server.jndi.ServerContextFactory.afterStartup(ServerContextFactory.java:213)
at org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:263)
at org.apache.directory.server.core.jndi.AbstractContextFactory.getInitialContext(AbstractContextFactory.java:118)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
at org.apache.directory.server.Service.init(Service.java:96)
at org.apache.directory.daemon.Bootstrapper.callInit(Bootstrapper.java:151)
at org.apache.directory.daemon.MainBootstrapper.main(MainBootstrapper.java:79)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at org.apache.mina.transport.socket.nio.SocketAcceptor.registerNew(SocketAcceptor.java:429)
at org.apache.mina.transport.socket.nio.SocketAcceptor.access$900(SocketAcceptor.java:52)
at org.apache.mina.transport.socket.nio.SocketAcceptor$Worker.run(SocketAcceptor.java:258)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:43)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:619)
> Server Left in Unstable State
> -----------------------------
>
> Key: DIRSERVER-950
> URL: https://issues.apache.org/jira/browse/DIRSERVER-950
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.0
> Environment: FC6
> Reporter: Ole Ersoy
> Priority: Minor
>
> I can only give observational data
> for this, since it appears to be a one time thing.
> It's a little like the sequence of what happened depends
> on threads, and thread A completes first 9999/10000 times,
> but in this case thread B completed first...
> I ran the test:
> EObjectClassCreator
> It creates an ObjectClass and the
> AttributeTypes needed by the ObjectClass.
> I've ran it several times successfully already,
> but on the last run it left the server in
> a state that does not let me delete
> an entry shown in LS.
> I have a single entry (That should have been cleaned by the test)
> ou=objectClasses, cn=ecore, ou=schema
> This has no children.
> If I refresh in LS it is still there.
> I check to make sure the apacheds daemon is still running.
> If I try to delete I get this:
> Error while deleting entry
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> metatopsdo is an objectClass that was created in order to create
> the ObjectClass entry that the test creates.
> Once the test has run the ObjectClass entry
> created is deleted,
> then the metatopsdo ObjectClass.
> This is strange because the entry
> ou=objectClasses, cn=ecore, ou=schema
> is empty, at least as shown is LS.
> So the question is under what circumstances does
> is LS not able to delete an empty entry like this.
> I'm now going to disconnect and reconnect
> with LS to see if it has an effect.
> OK - I did that and
> when drill down past the entry
> ou=objectClasses, cn=ecore, ou=schema
> I get this:
> Error while reading entry
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> So the ObjectClass entry the test created
> must be there, but LS can't see it because
> the metatopsdo ObjectClass is deleted,
> at least it seems.
> But ApacheDS should disallow deletion
> of metatopsdo when it is being used by another
> ObjectClass entry right?
> I think the only thing I can do now is to
> reinstall the server...since the entry
> is "Stuck"...
> But first let me try restarting it
> just in case...
> yum still stuck.
> Just in case the teardown for this test looks like this:
> EObjectClassDestroyer.
> destroy(
> ecoreAttributeTypesContext,
> ecoreObjectClassesContext,
> eClass,
> oidPrefix );
> MetaTopSDOObjectClassDestroyer.
> destroy(
> ecoreAttributeTypesContext,
> ecoreObjectClassesContext,
> oidPrefix );
>
> EcoreTypeSystemDestroyer.
> destroy(
> ecoreSyntaxesContext,
> oidPrefix);
>
> super.tearDown();
> So it's really strange that it got stuck like this...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.