Bug 102891 - Creating UDCTs is not reliable in Multi-JVM environment
Creating UDCTs is not reliable in Multi-JVM environment
Status: CLOSED WONTFIX
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity high
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks: 108447 111508 102913
  Show dependency treegraph
 
Reported: 2003-08-22 09:11 EDT by Daniel Berrange
Modified: 2007-04-18 12:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-02 13:22:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2003-08-22 09:11:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314

Description of problem:
Part of creating a UDCT involves creating a dynamic object type (whose PDL is
stored  in the DB). When creating this new object tyep, it is automatically
added to the Metadata root after creation. Unfortunately, in a Multi-JVM
environment the other JVMs in the cluster don't get the new type added to their
Metadata root. Thus, after creating a UDCT, the other servers in the cluster
will throw errors when using the new UDCT.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create a new UDCT on Server A
2. Create an instance of UDCT on server A
3. Publish the instance
4. Try & view the instance on server B.

    

Actual Results:  An error is thrown

Expected Results:  The item is displayed.

Additional info:
Comment 1 Vadim Nasardinov 2003-10-31 10:50:58 EST
When/if this is resolved, we should also revisit bug 101658.
Comment 2 Daniel Berrange 2006-09-02 13:22:13 EDT
Closing old tickets.

Note You need to log in before you can comment on or make changes to this bug.