Location of alf_data configurable?

[whitecrowe]

Is the location of alf_data configurable? It is currenlty defaulting to C:\WINDOWS\system32 and I would like to configure it to a different drive.

[davidc]

Hi,

Yes it is.  The config value dir.root in the file repository.properties will do the trick.

If you already have data in your repo (likely), then you can:
- shut down your app. server
- make the changes to repository.properties
- copy exising alf_data (in c:\windows\system32) to your new location
- restart app. server

You can set an absolute path e.g. c:\alf_data.

[markthompson23]

Can the location of the content store be set at the Space level?  From what I can tell, I think the answer is no.

[derek]

Hi,

The ContentService implementation is called RoutingContentService.  So far, it only routes URLs to one store.  It would be possible to set up routing criteria and incorporate them in there - provided we knew what those criteria should be.

File size, mimetype, user and space are but a few options.   :cry:

Regards

[markthompson23]

So far, it only routes URLs to one store. It would be possible to set up routing criteria and incorporate them in there - provided we knew what those criteria should be.

Here is what I'm struggling with.  As far as I can tell, you can only select a single location for the content store.  Once I exceed the capacity of that location, what then?  It doesn't appear that I can then simply add a new server/storage device and continue.

I guess what I would like to see is a 'content store' property for the spaces.  It would default to the dir.root value but could be configured to route the content to other locations.  I'm sure this type of change would create other architectural challenges but being limited to a single location is crippling from a scalability perspective.

How are you handling it in house?  Do you just have a location capable of handling everything you throw at it or is there a way to configure the system to support multiple content stores?

[derek]

Hi,

I have treated these as two separate requirements:

1. Route content to a specific content store based on the content's metadata, node location, etc.
2. Route content to different stores based on simpler, metadata-independent criteria.

The first will be covered by the RoutingContentService as and when such a requirement becomes evident.  Routing all spaces' content to one store and all other content to another is also not scalable in the long run.  The space issue lies with 2, for which a solution has been provided for Enterprise customers.

Regards

[markthompson23]

Thanks for the response.

I wasn't necessarily advocating a meta-data solution over a meta-data independent solution.  It was just the one that came to mind.

I'm glad to hear you have already provided for this in the Enterprise version which makes sense since that is where you would expect scalability issues to come into play.  I checked the comparison charts of the different products but I didn't see it (I guess you could say it would fall under 'Clustering'.)

[derek]

I guess you could say it would fall under 'Clustering'

Yes.  Clustering and replication naturally have to share content between stores.  Sharing and duplicating stores arose naturally out of this.  The same component is configurable to support the different scenarios.

Regards

[vidya_r]

Hi,

I have treated these as two separate requirements:

1. Route content to a specific content store based on the content's metadata, node location, etc.
2. Route content to different stores based on simpler, metadata-independent criteria.

The first will be covered by the RoutingContentService as and when such a requirement becomes evident.  Routing all spaces' content to one store and all other content to another is also not scalable in the long run.  The space issue lies with 2, for which a solution has been provided for Enterprise customers.

Regards

Has this been covered in the latest Alfresco release?  I have a requirement to move contents to different stores based which space they come from.
Please reply.