nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Virtualization Server does not start

mcmagi

Hello all,

I am receiving the following exception in the catalina.out when I attempt to start the virtualization server. It was working before and I didn't make and configuration changes to the environment since then.

Apr 30, 2007 5:05:13 PM org.alfresco.mbeans.VirtServerRegistrationThread registerVirtServer
INFO: Connected to remote Alfresco JMX Server
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Caused by: java.lang.NullPointerException
        at org.alfresco.catalina.host.AVMHostConfig$AVMWebappDescriptor.setParentRepo(AVMHostConfig.java:2038)
        at org.alfresco.catalina.host.AVMHostConfig.deployAVMWebappsInDependencyOrder(AVMHostConfig.java:1014)
        at org.alfresco.catalina.host.AVMHostConfig.deployAllAVMwebappsInRepository(AVMHostConfig.java:403)
        at org.alfresco.catalina.host.AVMHostConfig.deployApps(AVMHostConfig.java:244)
        at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
        at org.alfresco.catalina.host.AVMHostConfig.start(AVMHostConfig.java:196)
        at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
        at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
        at org.alfresco.catalina.host.AVMHost.start(AVMHost.java:586)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
        at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
        at org.apache.catalina.core.StandardService.start(StandardService.java:450)
        at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
        … 6 more
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

This happened to me once before and the only way I was able to work around it was a total database wipe and reinstall of Alfresco. Unfortunately, since this Alfresco instance contains production data, I can't do the same thing again.

Any help would be appreciated. Thanks.

- Mike

Find more posts tagged with

Comments

mcmagi

I found a bug on this issue in JIRA:

http://issues.alfresco.com/browse/WCM-434

Is there some workaround available?

Thanks
- Michael C. Maggio
NCS Technologies

jcox

Were any of the versions you were working with nightly builds,
or were they all official builds at every moment you were entering
your content?

Un-patched schema changes from/to a nightly can cause a mistatch
between the indexed info in the database, and persisted content in
the backing store. This can then result in unexpected NULL pointers
being returned to the virtualization server via via AVMRemote, which
leads to an unrecoverable error (the data it needs just isn't there).

If every upgrade has been between official releases,
patches are avalable to move the data being managed
from one internal schema format to the other.   Patches
are not typically avalable for nightlies.

Could the problem you've reported be related to this?
If so, the easiest solution (though it's obviously a pain)
is to bundle your content up as a war file, save it off to
a normal file system, destroy/create the database,
remove the old backing store, and push the content
back in.   Nightly builds probably should come with
announcements of schema changes, to make this
less of a nasty surprise.    Otherwise, just use official
releases/patches.

mcmagi

Hi Jon,

I haven't used any nightly builds. I'm only using the official community 2.0.0 release. The last time this happened to me, I was using the 2.0 preview, but that was in my development environment (which is currently fine) and I had completely wiped its database for the upgrade to 2.0 official.

Also, someone reported in the JIRA issue that they received this error after they deleted a web project and I believe I may have done the same during my first load of the web project (it was a few weeks ago, so I'm going on memory). The virtualization server remained running (and functional) since that time until I restarted it yesterday.

Thanks,
- Michael C. Maggio
NCS Technologies

jcox

In addition to wiping the database, you must also purge
the backing store (i.e.: the alf_data dir).     Old backing
stores can have stuff that ends up confusing the database
(even a fresh one)… even if it looks like things "work"
for a while.

The reason I'm exploring this possiblity is that there's
no reason why AVMRemote should return a null pointer
here, unless something in the repository got mixed up;
given the overall solidity of the AVM, it seems that the
most probable ways for this to happen is when something
out-of-band occurs, such as an unpatched or unsucessfully
patched old version.

If there *is* a problem with the patch, I'd expect more
folks would have hit it, but then maybe there are ways
it can be partly-but-not-completely sucessful.   This isn't
my area of expertise, but I'll try to learn more about it.

That said, it's quite easy to forget to also remove an old
backing store & have that come back to bite you later on.
I've done this myself more than once.   This is my best
guess as to what's going on.

mcmagi

Hi Jon,

Yes, both the database and the backingstore (even the entire alfresco directory) were all purged. However, (and I apologize if I wasn't clear on this above) the upgrade from 2.0 preview to 2.0.0 official was made in the development environment, which is currently fine. I only mentioned it to demonstrate how I've dealt with the problem before. Our production environment - where I am seeing the above problem - was a clean install of 2.0.0 community official. No prior versions, no prior data, no nightly builds, and no patches applied.

Thanks,
- Michael C. Maggio
NCS Technologies

jcox

Just to follow-up, did you get your issue resolved?

- Jon

mcmagi

Hi Jon. Yes, I did get past this, but I did so the same way I worked around it the first time - by wiping Alfresco's database and data directories, then re-importing everything under a new web project. I did so before you posted the fix for WCM-434 so I never had the opportunity to test it.

Thanks for the follow-up.

- Michael C. Maggio
NCS Technologies