(SOLVED) JBAS-7674 solution for JBoss 5.1?? (Windows lock on jnp-service.url)
riskyseven May 20, 2010 11:36 AMHi all. I'm currently updating a large application from JBoss4 to JBoss5.1. I'm made it past many many issues but am now stuck.
JBAS-7674 pretty much describes my issue. I need to use JBoss5.1, and can't migrate to JBoss6 at this time.
My upgrade work is being done in Cygwin, to be deployed to Solaris at a later date. In a nutshell, if a running server is stopped w/ a 'kill <pid>' command, there is a lock in Windows on <server>/data/jnp-service.url. The server process is successfully killed off, and this lock is owned by the Windows system Explorer process....can't really kill that one. If I try to start the server back up, everything blows sky high, root cause being that file permissions on this file (partial dump below if interested). Using Sysinternal Process Explorer (love this utility!), I can pinpoint the lock on the Explorer process, and can manually release the lock w/ no ill effects. After this release, I can restart the server successfully. This use case can be reproduced using the standard <jboss>/bin/run.sh server.
Any ideas on how I can get past this? If there is a scripting solution that will work within Cywin/UNIX, this would be ideal....I just don't know how to do this. Another thought was to recompile JBoss5.1 w/ the JBoss6 MR2 fix, but I'm not fond of running w/ a custom rolled JBoss5.1 and would like to avoid it if at all possible...haven't researched if this is even possible.
Has anyone worked around this? Any help would be greatly appreciated. Thanks.
14:35:16,357 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/^M
14:35:16,732 ERROR [AbstractKernelController] Error installing to Start: name=jboss:service=NamingProviderURLWriter stat
e=Create mode=Manual requiredState=Installed^M
java.io.IOException: Access is denied^M
at java.io.WinNTFileSystem.createFileExclusively(Native Method)^M
at java.io.File.createNewFile(File.java:883)^M
at org.jboss.naming.NamingProviderURLWriter.start(NamingProviderURLWriter.java:117)^M
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)^M
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)^M
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)^M
at java.lang.reflect.Method.invoke(Method.java:597)^M
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)^M
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)^M
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)^M
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)^M
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)^M
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)^M
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)^M
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)^M
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)^M
at $Proxy38.start(Unknown Source)^M
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)^M
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)^M