Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Not able to use this add-on #31

Open
sagar-nimmala opened this issue Oct 23, 2020 · 27 comments
Open

Not able to use this add-on #31

sagar-nimmala opened this issue Oct 23, 2020 · 27 comments

Comments

@sagar-nimmala
Copy link

Hi Axel,

I have alfresco 6.2 community installed, it is working fine. After that I have applied Alfresco-simple-content stores amp.

Now I am trying to add simple store (standardFileStore), while doing that i am getting not able to some content and alf_data not pointed to correct location error.

I tried with Aggregating store, there I am getting error Error creating bean with name 'myAggregatingStore': Cannot resolve reference to bean 'fileContentStore' while setting bean property 'secondaryStores'

Can you please help me in fixing this.

Thanks,
Sagar
@sagar-nimmala sagar-nimmala changed the title Notable to use this add-on Not able to use this add-on Oct 23, 2020
@AFaust
Copy link
Member

AFaust commented Oct 23, 2020

Your configuration is partially not correct. I realise that the example configuration in the documentation of the aggregating store does mention fileContentStore, but the correct name for the default store is actually defaultTenantFileStore, as outlined in the general configuration documentation.

@sagar-nimmala
Copy link
Author

Hi Alex,

I have changed my configuration to defaultTenantFileStore, but still I am getting the error as below.
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'defaultTenantFileStore' available.

Below is my configuration.

dir.root=C:/Alfresco/alf_data
dir.keystore=C:/Alfresco/alf_data/keystore

simpleContentStores.enabled=true

simpleContentStores.customStores=myCustomFileStore,myAggregatingStore
simpleContentStores.rootStore=myAggregatingStore

simpleContentStores.customStore.myAggregatingStore.type=aggregatingStore
simpleContentStores.customStore.myAggregatingStore.ref.primaryStore=myCustomFileStore
simpleContentStores.customStore.myAggregatingStore.list.ref.secondaryStores=defaultTenantFileStore
simpleContentstores.customStore.myAggregatingStore.deleteContentFromSecondaryStores=false

simpleContentStores.customStore.myCustomFileStore.type=standardFileStore
simpleContentStores.customStore.myCustomFileStore.value.rootAbsolutePath=C:/Alfresco/alf_data/myContentStore
simpleContentStores.customStore.myCustomFileStore.value.deleteEmptyDirs=true
simpleContentStores.customStore.myCustomFileStore.value.protocol=store
simpleContentStores.customStore.myCustomFileStore.value.fixedLimit=104857600

@AFaust
Copy link
Member

AFaust commented Oct 27, 2020

If you read the linked config section, you still have to list the defaultTenantFileStore in the simpleContentStores.customStores property.

@sagar-nimmala
Copy link
Author

Hi Alex,

Thanks for quick reply, I have added defaultTenantFileStore in the simpleContentStores.customStores, then i get error as below.
ERROR [org.springframework.web.context.ContextLoader] [main] Context initialization failed
org.alfresco.error.AlfrescoRuntimeException: 09270018 defaultTenantFileStore (custom content store) has not been given a type

Please find my configuration below.
dir.root=C:/Alfresco/alf_data
dir.keystore=C:/Alfresco/alf_data/keystore

simpleContentStores.enabled=true

#simpleContentStores.customStores=myCustomFileStore
#simpleContentStores.rootStore=myCustomFileStore
simpleContentStores.customStores=myCustomFileStore,myAggregatingStore,defaultTenantFileStore
simpleContentStores.rootStore=myAggregatingStore

simpleContentStores.customStore.myAggregatingStore.type=aggregatingStore
simpleContentStores.customStore.myAggregatingStore.ref.primaryStore=myCustomFileStore
simpleContentStores.customStore.myAggregatingStore.list.ref.secondaryStores=defaultTenantFileStore
simpleContentstores.customStore.myAggregatingStore.deleteContentFromSecondaryStores=false

simpleContentStores.customStore.myCustomFileStore.type=standardFileStore
simpleContentStores.customStore.myCustomFileStore.value.rootAbsolutePath=C:/Alfresco/alf_data/myContentStore
simpleContentStores.customStore.myCustomFileStore.value.deleteEmptyDirs=true
simpleContentStores.customStore.myCustomFileStore.value.protocol=store
simpleContentStores.customStore.myCustomFileStore.value.fixedLimit=104857600

@AFaust
Copy link
Member

AFaust commented Oct 27, 2020

Ok - this error has revealed two issues:

  • I made a copy&paste mistake (actually I typed it instead of doing a copy&paste) from my own documentation
  • you have indeed not read the linked documentation

The value defaultTenantFileStore is incorrect, and it should have been defaultTenantFileContentStore

@sagar-nimmala
Copy link
Author

Thanks Alex,

Now it is working.

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Oct 29, 2020 via email

@AFaust
Copy link
Member

AFaust commented Oct 29, 2020

You already commented on #29 and likely saw my reply in that thread that said "encrypting existing content is not automatically done" - this means there is no job to run etc.
With your configuration, existing content would never be encrypted, as you have put the encrypting store in an aggregating content store. Only new versions / new files would ever be encrypted.
If you used a property or site routing instead of an aggregating content store, then existing content would be encrypted as soon as you trigger a change on the node that affects where its content is to be stored, e.g. update the selector property or move it between sites. Note that:

  • this is only able to encrypt the "current version" of the node
  • unencrypted content may still be referenced by other nodes (e.g. when copied / or frozen version nodes)
  • oboslete / orphaned unencrypted content is deleted in accordance with Alfresco's standard handling of orphaned content (typically with 14 day delay)

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Nov 2, 2020 via email

@AFaust
Copy link
Member

AFaust commented Nov 2, 2020

There is a slight error in the Readme-Link, the correct one is https://github.com/Acosix/alfresco-simple-content-stores/blob/master/docs/SelectorPropertyStore.md

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Nov 2, 2020 via email

@AFaust
Copy link
Member

AFaust commented Nov 2, 2020

I don't know how I can help / support you more (except for giving you ready-to-use code for your environment, which I obviously can't and won't) other than advising you to:

  • configure a property routing content store with the default file content store as the default / fallback store and the encrypting store as a store mapped to a specific property value (you can use the default content store selector aspect or an aspect of your own)
  • option a) configure a form or action in whatever UI you are using (Share / ADF) to change the value of the selector property and execute a property change for any document you want encrypted
  • option b) implement / run a script, job or action which processes batches of your existing documents to change that selector property without minimal / no user interaction

You have the documentation of the selector store (correct link provided in my last response), and problably know best about your system, UI and custom metadata model to decide which of the option you need / should take.

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Nov 2, 2020 via email

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Nov 3, 2020 via email

@AFaust
Copy link
Member

AFaust commented Nov 4, 2020

Use selectorPropertyRoutingStore instead of selectorPropertyStore - apparently the name was changed at some point but the documentation was not yet updated.

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Nov 5, 2020 via email

@AFaust
Copy link
Member

AFaust commented Nov 5, 2020

You are missing the moveStoresOnChange property in your configuration.

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Nov 5, 2020 via email

@AFaust
Copy link
Member

AFaust commented Nov 5, 2020

Documentation: "This functionality must be explicitly enabled via the configuration."

@sagar-nimmala
Copy link
Author

Hi Axel,

I have added moveStoresOnChange=true, but the content is being copied is not moving from default store. As a result the disk space is growing. Can you please tell me how can I move instead of copy.

Thanks,
Sagar

@sagar-nimmala sagar-nimmala reopened this Mar 17, 2021
@AFaust
Copy link
Member

AFaust commented Mar 17, 2021

I refer you again to the documentation: "Instances of this store type will only ever copy contents between backing stores. Similar to Alfresco default behaviour for deleting content, the content in the old location will not be actively deleted by default. If the previous content URL is no longer associated with any other content data instance in Alfresco, the URL will be marked as an orphan and be be eligible for a move into the contentstore.deleted directory after a configurable grace period (default 14 days) has elapsed. By configuring the Alfresco orphan cleanup to be "eager", that is immediately process any orphaned content URLs at the end of a transaction, the copy operation of this store can effectively be turned into a move operation."

The Alfresco documentation explains the orphan handling and most configuration properties related to it. What it lacks is the mention of the flag for eager content cleanup which needs to be set in alfresco-global.properties to enable (almost) immediately deletion of the old file. NOTE: This is a global flag which does not only affect this content store, but any handling of content in Alfresco. Use this with caution and only if your backup / recovery process can deal with it.

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Apr 8, 2021 via email

@AFaust
Copy link
Member

AFaust commented Apr 9, 2021

If you configured your file store to use a different protocol to ensure that content URLs are unique between the default and the encrypted store, Alfresco would cleanup the old content after the orphan grace period. Since your simpleContentStores.customStore.myCustomFileStore.value.protocol is set to store, which is the default protocol in Alfresco, the content URL after copy into the encrypted store is identical to the original content URL, and Alfresco is unable to detect it as being orphaned, so can not clean up the original one from the unencrypted store. Change the protocol to something unique, and you will see that the default orphan handling of Alfresco will take care of removing duplicates (note: existing duplicates before the configuration change will not be cleared up - you'd have to toggle the store selector once to the original value and back to the encrypted store value, so it runs through the copy one more time, resulting in a unique content URL).

@sagar-nimmala
Copy link
Author

sagar-nimmala commented Apr 9, 2021 via email

@AFaust
Copy link
Member

AFaust commented Apr 11, 2021

Apparently if you sent comments to GitHub via email, the attached / inlined images are not properly carried over, so I don't see your screenshot. Have you made sure that the orphan protect duration is sufficiently low or that eager orphan cleanup is enabled? Otherwise (if Alfresco default configuration is used), it is normal that the file is still there and remains there for up to 14 days.

@sagar-nimmala
Copy link
Author

Hi Axel,

Please find the screenshot here. I haven't enabled eager cleanup but, it has been more than 15 days so it should be cleaned up.
image

Thanks,
Sagar

@AFaust
Copy link
Member

AFaust commented Apr 12, 2021

And have you checked which node is referencing the old content_url? If the node in question uses versioning, then any old version of that node still references the old content URL and it will never be orphaned as long as the old version is not deleted. When Alfresco versions nodes, the values of the properties are decoupled, so if you move the content for the "current" version, the old version is unaffected by this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@AFaust @sagar-nimmala