Products

Solutions

Resources

Partners

Community

About

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsGalleryGalleryHow to make gallery staticHow to make gallery static
Previous
 
Next
New Post
1/12/2010 12:25 PM
 

I have a fairly large gallery that I keep getting the error The process cannot access the file 'E:\inetpub\vhosts\mysite.com\httpdocs\Portals\0\Gallery\mygallery\_metadata.resources' because it is being used by another process.

 (Details at http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/9/threadid/342999/scope/posts/Default.aspx, logged in gemini)

This error seems to be related to large galleries and caching, which can be found by searching google for "_metadata.resources' because it is being used by another process". 

My gallery is pretty static (i.e. not planning on adding any new photos to it).  I tried to increase the "Cache Duration" in the module page settings to something large like 60000, but this actually caused the gallery to NOT load at all. 

Is there a way to make the gallery a static gallery with only the images it h as in it now.. and build the cache once and NOT rebuild it till something is added or changed?

Thanks!

 

 
New Post
1/15/2010 4:22 PM
 

I have spent quite a bit of time analyzing this error using a test gallery of some 500 image files added via the file system and make the following comments:

_metadata.resources is an xml file located in the top level gallery and each child folder of a gallery. Whenever a page containing the gallery module is visited following a period of inactivity, the elements of this xml file must be reread to build a collection of folder and media file items. This collection is then cached to make subsequent visits to the gallery load more quickly. Each time a new child album or media file (via the module interface or via FTP) is added to a gallery album or any changes are made to a media file's metadata, this xml file must be rewritten. The more media files already contained in the gallery or the more being added, the longer the process of rewriting the xml file will take. It is during that time should another user visit the gallery triggering the rewriting process that this error will be thrown.

Once the xml file is completely written, any subsequent visits to the gallery, even if the cached data has expired, will require only reading, not writing the xml file. Voting will, however, require a rewrite and probably should be disabled for a large gallery.

Should the initial rewrite of the xml file following the addition of media files be interrupted by this error being thrown when another user visits the gallery or a user becomes impatient and clicks on another page or album link, the _metadata.resources file may never be completely built thus triggering a rewrite and more of these errors each visit to the gallery. This is what I suspect is happening in your case, even though you are not adding any more files or making edits to the gallery.

If you could take a look at the _metadata.resources files in the top level gallery and each child album and advise if a) there is a <file> node for each and every media file in the gallery; b) if the <id> node of each <file> node contains an integer and c) the <approveddate> node of each <file> node contains a date either earlier than the current date or the minimum date marker which begins with 9999-12-31, it would be helpful. If you would prefer, you could email the _metadata.resources files to me at bill(at)wesnetdesigns.com.

This form of data caching is not at all related to the module's cache time which controls output caching and which (as you found out) cannot be used for any interactive module. It is not possible nor desirable to disable the data caching of the gallery metadata.

You might also try to temporarily set the view permissions of the page containing the gallery to exclude all users except yourself, click on the refresh icon in the top or bottom left of the gallery, and give the gallery sufficient time to complete rebuilding the _metadata.resources files, then reset the page view permissions to open the gallery to all users. Once the xml files have finished rebuilding and provided you make no changes or additions, this error should not continue to occur.

 


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
1/17/2010 9:47 PM
 

Thanks Bill -

I'll look into it.  A strange thing happened that I can't explain a few days ago.... the metadate file reverted to making NONE of the files approved.

When I uploaded the gallery, I uploaded the jpg files to a folder via FTP.  I didn't have time to upload them one at a time via the gallery module, and the gallery is too large to upload as one big zip file.

Eventually I'll try FTP'ing the original jpg files to a different new folder and then make a new gallery module pointed to the new folder.

I'll let it load fully.

Some questions:

-If I open the gallery as a host account, does it automatically rebuild the metadata?  If so, can this feature be disabled?

-I have voting disabled.. why is there a need to rebuild metadata at all if nothing is changing?  For example... why can't the upload of a new file, or adding a vote, etc be the triggers for updating metadata, rather than having the host account open the gallery trigger an "update".  At the very least, maybe this should be a function that can be disabled.

-Perhaps there should be a function to "rebuild gallery metadata" that the user has to trigger himself if auto-rebuild is turned off?

 

 

 

.....I might take you up on sending the metadata.resources file in the future. Thanks!

 

 
New Post
1/18/2010 9:34 AM
 

The _metadata.resources files should only be rewritten when files are added via FTP or any change is made to gallery metadata such as editing an album or file, voting, or opening the gallery configuration page. This should be true even if the host account is the one accessing the gallery. There is already a manual refresh button available to admin/host user should it be necessary to force a rebuild of the metadata.

Your comment that the metadata file reverted to making none of the files approved is of particular interest and bears further examination. Am I correct that Auto approval is enabled in the configuration? What is the default culture of your portal (e.g en-US or something else)? When you have a chance, please e-mail me one or more of the _metadata.resources files.

Also, what version of DotNetNuke framework are you running?


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsGalleryGalleryHow to make gallery staticHow to make gallery static


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out