DEMO : Alfstore – Alfresco Portlet for IBM WebSphere Portal

March 14, 2011

Alfstore has just released the version 2.0 of the Alfresco Portlet for IBM WebSphere Portal.

For more details on the portlet features, visit Alfstore module webpage

WATCH THE PORTLET DEMO


Integrating Alfresco with Social Software / Principles and real life use-cases

January 28, 2011

 

Our company (www.alfstore.com) just delivered a new Widget component to integrate Jive (Enterprise Social Networking solution) with Alfresco ECM platform.
I think this project is a good example of how Alfresco social foundation can be integrated with another social software, dedicated to Enterprise social networking.

This Widget is in production now since a few days, used by one of the biggest French industrial company. basically, it gives Jive users the ability to browse and access Alfresco library from their Jive dashboard:

Jive Widget for Alfresco

Jive Widget for Alfresco

It’s a little bit too early to speak about this new Widget component features and its roadmap, but of course we plan to build an Enterprise supported version, for other customers.

So this post is not about the Widget itself (yes more technical communication will come later on), but about all the thinking that lead to the current v1.0 design, and why we have selected this approach to start with.
I think this might be of interest because this could apply to other similar projects of integration between Social Software, and ECM (not only Jive / Alfresco).

——————–
Summary
For people who have a very limited time to read, here is the synthesis of the approach:

Generic:
ESN = Enterprise Social Networking Tool = Front-End = Place to collaborate around document
ECM = Foundation for Content Management = Back-End = Document Repository
Integration = ESN view component = Window to expose and browse ECM data

Example:
JIVE = Enterprise Social Networking Tool = Front-End = Place to collaborate around document
ALFRESCO = Foundation for Content Management = Back-End = Document Repository
Integration = JIVE Widget = Window to expose and browse ALFRESCO data

——————–
General questions about use-cases:
During the specification phase of the Jive-Alfresco widget, we had to address the following questions about the global design and the responsibility of each IT system:

Let’s assume my company uses both an ESN tool (like Jive), and an ECM tool (like Alfresco):
– For a new document (available on my desktop) : should I publish it in Jive first or in Alfresco first ?
– What about existing documents ? If the document is already in Jive, when and how (and why ?) should I push it to Alfresco ?
– If the document is already in Alfresco, how can I push it to Jive ?
– If I add a tag, a rating or a comment on an existing document, should I synchronize also this meta-data to the other system along with the doc binary ?
– When a document is moved from one system to another, should I keep a copy or a reference in the source system ?
– etc, etc, etc.

So we had to address some infra/IT questions, as well as functional questions…But the main question to answer first was: where should I finally store my document and/or data ?

————————–
Infrastructure perspective: ESN/ECM system responsibility
Actually, the answer to the previous question is quite obvious (at least for me).

Yes ESN systems are used to manage a lot of data (documents, images, video, etc)…but they are usually not designed as highly scalable data repository. They are primarily designed to improve collaboration, and to ease social networking.
Think about your youtube video : you will upload them first in youtube (youtube is the highly scalable storage), and then exposed them in your web site. So you can consider Alfresco as the youtube for documents, and Jive as the front-end application that needs to expose documents to allow collaboration.

So it was clear for us that the final document and data repository should be the Alfresco ECM system…But now, more and more, conversation will start in the ESN system first….how could we manage that ?

————————–
Document life cycle / Social and collaboration creation process
Actually, the good question about storage location and responsibility might be where should I store my documents in the short, middle or long term.

With new ESN systems, document creation will be more and more a collaborative process and documents will likely have to be moved from one storage to another during their life cycle. For instance:

Short term: for a new “draft” document, the first storage location could now be ESN. The “document” could be already a draft document (word, excel, etc), but it could also just be a web piece of content (blog post, wiki page), or just an idea (forum discussion, comments).
Middle term: once the document is “finalized”, it should be moved to the Document Management system (ECM). Document can still be modified, but less frequently. Security/Control are important here, because we need to have fined grain control on the reader audience.
Long term: for long term storage, you might need to move the document in an archiving system.

So yes, you finally will have to deal with long term storage strategy/archiving, retention policies, security policies, etc…I know it’s not as fun as doing social networking, but you need to take care about your documents. You need some form of control to keep and manage this company knowledge in the long term so that someone else (another employee) could securely but easily find it, and could re-use it.
Important documents should not stay forever in your ESN system…otherwhise, you might loose informations…

————————–
Selected use-cases:
Based on the previous architecture rules for document storage location, we have then defined the main principles and the selected approach in our case (for this Jive-Alfresco Widget). To summarize them quickly:

For an existing and finalized document (think word, excel, etc):
– User should store it in ECM (Alfresco) first.
– To collaborate around this existing document, go to your ESN tool (Jive),
– From Jive, browse your ECM document library (using our Widget of course !), get the ECM document reference (link) and use it to start a discussion, or include it in any ESN item (blog post, wiki page, etc).

For a “draft” document:
– It could be uploaded in ESN tool first (could be a draft, but it could also just be a web piece of content, or just an idea).
– ESN (Jive) is then the tool used to collaborate around document,
– Once the document is “finalized”, it should preferably be moved to the ECM system (Alfresco).

————————–
Operations on document:
Once the responsibility of each system is clearly defined, as well as use-cases, it is time to detail the operations available on documents/folders:

Basically, there are 4 main kinds of operations identified in our scenario:
– Browse ECM folders/documents (from the ESN interface),
– CRUD operation on document (from the ESN interface),
– Move document (from ESN to ECM system),
– Collaborate around document (using the ESN tool).

Browse ECM folders/documents from the ESN interface:
Basically, you need to build an ESN view component (Jive Widget in our case), and then use appropriate framework to build the dynamic view (Struts, YUI, etc).
For those who are familiar with Portal, a Widget is functionally “similar” to a Portlet.

Jive Alfresco Widget view

Jive Alfresco Widget view

CRUD operation on document/folder:
You need at least to implement the basic document management feature (create, update, delete, rename, etc), and to expose them in the ESN interface (Widget). This can easily be done using one of the Alfresco Web Services (REST, SOAP, CMIS, etc).
For instance, you need an upload “wizard”, to put document in Alfresco, directly from the Jive web interface.

Document Menu

Document Menu

Folder Menu

Folder Menu

Upload file wizard

Upload file wizard

Move document (from ESN to ECM system):
The purpose of this feature is to move the document binary from the ESN system to the ECM system, once it has been finalized.

This “Move To” feature has not been implemented for the moment, in the v1.0 of the Widget. Actually, it was quite complex to manage (as Jive is not open-source), and you need to have full control on the ESN code and data model to implement it. Also, there are several options to do it (duplicate file binary, keep meta-data in ESN after the move operation, remove meta-data from ESN, etc). We had limited time to deliver v1.0, and wanted to keep the system as much simple as possible, mostly to avoid any painful upgrade due to big system customization…Anyway, this feature will likely be scheduled for v2.0.

Note: if you want an example of such “Move To” feature, you can have a look at the existing IBM Quickr and Alfresco integration (more info). The scenarios described above have already been implemented by IBM/Alfresco (duplicate, detached, etc).

And the last scenario is “collaborate around document” (see section below).

————————–
Jive social content management features:
In our scenario, collaboration around the document is managed in the ESN system (tagging, rating, comments, discussions, etc).

When the document is uploaded directly in the ESN tool, then it is quite easy to do: your ESN system usually provides mechanism to collaborate around its own objects (whether it is a document, a blog post, a wiki page, a news, etc).

But when document is stored in the ECM, you need to find a way get its reference (nodeID, URL, etc) to refer to it from the ESN system.

We had 2 main technical constraints:
– First we wanted the 2 systems (ESN/ECM) to be loosely coupled (we use Ajax to browse the ECM tree structure),
– We wanted to be able to use the ECM doc reference (Alfresco nodeID) in all kind of Jive object (Jive Documents, Blog, Wiki, Discussion, etc).

So it has been decided to simply implement a “Copy link to clipboard” feature, on each document:

Jive-Alfresco Widget : copy link to clipboard

Jive-Alfresco Widget : copy link to clipboard

 

The use case for the “Copy link to clipboard” is as follows:
– The Jive user browses the Widget folder tree view, and copy the link of the target Alfresco document,
– Then he/she creates a new Jive Object (Jive Documents, Blog, Wiki, Discussion, etc), and paste the link in the corresponding Jive HTML rich text editor, using the standard Jive insert link wizard.

Yes it’s basic, but it works well :-)…and also it is very easy to maintain (no Jive code or data model customization here), so no regression expected during the Jive software upgrade. For the next version of the Widget, we might consider using the new Jive activity stream feature…to provide a more integrated experience…to be studied.

————————–
Conclusion
This Widget component is a first example of how the Alfresco/ECM foundation could be integrated with ESN/Jive system.
It’s a first step, we know we can do much more with social software integration.

So what are the next steps ?
This v1.0 of the Widget is deployed in Jive production environment at customer site, and used by thousands of users. We are waiting for customer feedback to gather evolutions request, and improve next releases. We are planning to build a GA Enterprise version as soon as possible, for other customers.

Before this Enterprise release is ready, if you want to test it, feel free to contact us: info@alfstore.com


1 reason to choose Alfresco vs Quickr for document management : scalability

January 26, 2011

More and more people are asking me the same questions about IBM Quickr vs Alfresco Document Management solution.

Basically:
– what are the main technical and/or functional differences between Quickr and Alfresco ?
– When should I use Quickr, when is Alfresco more appropriate ?
– What is the best solution for document management ?
– etc.

I have already published a few blog post about this topic (see list below), but to summarize:
– Alfresco is a Document Management system, Quickr is not.
– Alfresco is a scalable solution, Quickr is not.

OK…let me give you more details 🙂

– Alfresco is designed as a highly scalable document repository, and can store huge volume of documents, Quickr cannot.
– Alfresco has a very light and robust software infrastructure, which allow to support a lots of concurrent users. Quickr is much more limited.
– From the hardware point of view, Alfresco can run on a very small server, with a few CPU/RAM resources. Quickr relies on a portal application architecture, so it is a quite heavy solution.
– Quickr is primarily a collaboration tool, Alfresco (now with Alfresco Share) also offers collaboration capabilities.

As you can see reasons seem more technical than functional, and that’s true.

If you study the respective DM features of each product, a high level functional analysis might show that these 2 solutions seem to offer the “same” level of service (versioning, security management, checkIn-Out, tagging, etc).

OK, but what if your end-users request (in the middle/long term) more advanced features like workflows/BPM, automated rules, archiving, etc…Then Alfresco will be more adapted.

If you are already using Quickr for document management/collaboration, for a limited number of users, and with a *very* small volume of data (50 GB, 100 GB ?), then you might think that switching to Alfresco does not make sense (due to cost of migration) in the short term…

OK, but I’m almost sure that your volume of document is growing quickly each day…right ?
(Even if it is not the case, just from the infrastructure cost perspective, you should consider Alfresco to reduce your hardware budget…).

So one of the main reason to choose Alfresco is its capacity to manage a huge volume of documents.
Scalability is the key argument. Be sure that, whatever the DM system you will implement in your company, people will very quickly adopt it (just because so far they had no other place to store their data), and the number of documents in your repository will grow faster and faster. Not only documents, but also images, videos, blogs, wiki, etc.
So sooner or later (but most likely sooner that you would expect), you will have to deal with hundreds of gigabyte of data or terabyte of data…and this is clearly not something Quickr is able to support.

Finally, I’m not saying that Quickr is not a good solution. My point of view here is that it is more a portal/collaborative solution, than a DM system.
So IBM Quickr could be an appropriate solution, for collaboration use-cases, portal integration, etc, but not as a document management solution.

Related posts:

Quickr and ECM relationship

Quickr and ECM integration

IBM and Alfresco partnership : Portal, Collaboration and Social Networking


Alfresco Portlet for IBM WebSphere Portal (JSR-286)

October 17, 2010

 

Alfresco document management features now available for IBM WebSphere Portal

 
Alfstore (www.alfstore.com) is proud to announce the release of a new Portlet for Alfresco that has been certified to run on IBM WebSphere Portal, and other JSR-286 Portal containers (as Liferay).

The treeview portlet exposes the content of an Alfresco space in the tree-view way. It provides all in-line editing features for documents and folders.

The user can then easily access to his/her documents, through a portal, using an ajax-style view. Only the common document management operations are exposed, to make the interface as simple as possible:

Actions on documents:
– Create (upload), Update, Delete,
– Edit : user can edit and save a document directly online from the portal (using the CIFS or the WebDAV protocols).

Actions on folders:
– Create, Delete, Refresh, Rename.

An advanced configuration mode allowing flexible appearance and functionality tuning. For example, the CIFS protocol can be disabled, and the user can select a specific space as the “root folder” to start the navigation.

So the “complexity” of the Alfresco standard interface is hidden, and this Portlet can really be used by none advanced users.

The Portlet layout is light and small so it can be integrated on a multi-column page with others portlets.

Technology:
– This Portlet was written for the IBM’s WebSphere Portal first of all (and fully tested on it), but does not use any WebSphere specific functionality, so it can run on others JSR-286 portals.
– The Portlet uses the standard Alfresco Web Service, and is compliant with Alfresco DM v2.x, 3.x.

Support:
– A free (not supported) open source version can be downloaded on Alfresco forge (http://forge.alfresco.com/projects/alftree-portlet/).
– A basic SSO mechanism is provided, so Portlet can be easily tested.
– The Enterprise version will be available shortly (end of Oct. 2010)for Alfresco customers.
– The Enterprise version will be fully supported by Alfstore and will be updated in lock-step with new versions of Alfresco and/or WebSphere Portal.

Enterprise version:
– Along with a professional support, the commercial version will include more advanced features, like:   
– Support for Enterprise SSO solutions (SSO CAS, IBM, Siteminder),
– Search features (search Alfresco documents from Portal),
– Multi-file upload,
– etc.

Learn More:
– Please feel free to contact us (info@alfstore.com) for more information.
– The detailed roadmap of this component will be updated on the Alfresco wiki.
– A webinar will also be presented in the near future.
– Company website : http://www.alfstore.com


Alfresco launches services to simplify migration from your legacy and proprietary ECM

June 2, 2010

As part of the campaign « switch to Alfresco », Alfresco has launched a packaged migration services, to help organization migrating from their current (and costly 🙂 ECM system to Alfresco.

The migration services will initially be available only for EMC/Documentum and Microsoft SharePoint.

As far as I know, Alfresco has made a partnership with a well known “connector editor” company (I think we can say it is EntropySoft), which will provide the set of tool to automate the data migration.

We have already tested such data migration toolkit provided by EntropySoft (for the migration from IBM “Portal Document Manager” to Alfresco repository), and I can say these are very good migration tool.

For more info : Switch to Alfresco


Upgrade path from 2.x to 3.2 : some tuning and recommendations (Part 2)

May 27, 2010

Previous post : Upgrade path from 2.x to 3.2 : some tuning and recommendations (Part 1)

Here are some other tuning recommendations that might help you to reduce the time of the Alfresco upgrade path, from 2.x to 3.2:

Please note that we have tested some of these “tuning” and that some of them, or a combination of some of them, could have a negative impact on the time of the upgrade path…So I recommend that you test these options carefully one by one first, and that you select only those which are relevant in your case:

——————————–
1/ If you experience OOM:

– Simply give more memory the heap (Xmx), if possible,
– Use the -XX:+HeapDumpOnOutOfMemoryError option so that the cause of the OOM can be analyzed afterwards through yourkit or other tools understanding hprof dumps (this cause no overhead, as heapdump file is created only if OOM occurs).

——————————–

2/ Increase transactional caches:

During upgrade path, you might see some log traces as follows:

18:14:01,264 WARN [org.alfresco.repo.cache.TransactionalCache.org.alfresco.storeAndNodeIdTransactionalCache] Transactional update cache ‘org.alfresco.storeAndNodeIdTransactionalCache’ is full (10000).

In our case, the support recommendation was to increase Cache Size as follows:

In cache-context.xml, increase maxCacheSize for the following:

authorityTransactionalCache from 100 to 5000

org.alfresco.personTransactionalCache from 1000 to 10000

org.alfresco.storeAndNodeIdTransactionalCache from 10000 to 50000

But do not set the ehcache caches too high or you’ll accumulate uncollectable cached objects in the JVM old gen, leading to more and more full GCs and leaving less room for the rest. Even if they is enough memory you’ll spend a large amount of time processing weak refs. it’s a memory / performance tradeoff.(see also next recommendation below).

—————

2/ Increase transactional caches can have a bad impact on JVM memory:

Increasing Transactional Cache can help in some cases, but on the condition that it does not fill up your old generation, which you cannot guess unless there is proper JVM monitoring and/ or heap dumps…

However, in some other cases, it might make sense, instead of increasing caches, to rather disable hibernate’s L2 cache for the upgrade path scenario…
This can be done by setting hibernate.cache.use_second_level_cache=false in alfresco-global.properties.

So clearly, this recommendation is not consistent with the previous one….But this is not surprising, since there is no “one true set” of settings that are written in stone. So test this option carefully, and use it only if you can see the improvement in your context.

——————————–
3/ Another option to try is to “make the hibernate session size resource interceptors more aggressive”:

You can try to make the hibernate session size resource interceptors more aggressive (see beans sessionSizeResourceInterceptor and sessionSizeResourceManager): as a result, the caches will be flushed more frequently (more frequent commit) and the old gen accumulation will grow more slowly (assuming that stateful persistence contexts associated with the threads might be an issue in your context):

By default, you should have:

<bean id=”sessionSizeResourceInterceptor”
class=”org.alfresco.repo.transaction.SingleEntryTransactionResourceInterce
ptor” <property name=”methodResourceManagers”>
<list>
<ref bean=”sessionSizeResourceManager”></ref>
</list>
</property>
<property name=”elapsedTimeBeforeActivationMillis”>
<value>10000</value>
</property>
<property name=”resourceManagerCallFrequencyMillis”>
<value>5000</value>
</property>
</bean>
<bean id=”sessionSizeResourceManager”
class=”org.alfresco.repo.domain.hibernate.SessionSizeResourceManager”>
<property name=”sessionFactory”>
<ref bean=”sessionFactory” />
</property>
<property name=”writeThreshold”>
<value>2000</value>
</property>
<property name=”readThreshold”>
<value>50000</value>
</property>
<property name=”retentionFactor”>
<value>3</value>
</property>
</bean>

You can try to set values as follows:

<beans>
<bean id=”sessionSizeResourceInterceptor” >
<property name=”methodResourceManagers”>
<list>
<ref bean=”sessionSizeResourceManager”></ref>
</list>
</property>
<property name=”elapsedTimeBeforeActivationMillis”>
<value>10000</value>
</property>
<property name=”resourceManagerCallFrequencyMillis”>
<value>100</value>
</property>
</bean>

<bean id=”sessionSizeResourceManager”>
<property name=”sessionFactory”>
<ref bean=”sessionFactory” />
</property>
<property name=”writeThreshold”>
<value>200</value>
</property>
<property name=”readThreshold”>
<value>200</value>
</property>
<property name=”retentionFactor”>
<value>0</value>
</property>
</bean>
</beans>

This config will allow to free more space in the old gen at each collection.

Don’t forget to use this setting only for the upgrade, not for production / runtime.

It may or not help, so once again, try it and use it only if this leads to upgrade time improvements….

——————————–
4/ Tuning the Linux swap threshold:

During the test of the upgrade path you should also check that the system is not swapping.

If it’s linux this can be controlled with the “vm.swappiness” kernel parameter, which can be set
safely to 10 (meaning don’t swap anything until ram is 90% full).
By default on Linux, this parameter is set to 40, which mean that system will swap as soon as memory is 60% full.

Note: we have not tested this tuning option during our upgrade path test.

——————————–

Hope this series of post will help you to complete a succesfull (and quicker) data migration !


Upgrade path from 2.x to 3.2 : some tuning and recommendations (Part 1)

May 27, 2010

I would like to share with you some information about the upgrade from 2.1.1 to 3.2 (Enterprise version) we are currently executing, and especially the time you should plan for migration if you have a big repository as we do…

1/ Description of the context:

So we have executed the upgrade path from 2.1.1 to 2.1.7 and from 2.1.7 to 3.2 (please note it is not
mandatory to go through 3.1.1, as validated by the support).

Upgrade path from 2.1.1 to 2.1.7 is quite quick (as there is no schema upgrade here).

However, the upgrade 2.1.7 to 3.2 takes approx. 40 hours in our case…!
So the first thing you have to take care is to plan for a downtime period (or at least read-only) of your source v2.x production system…The only way to assess the duration is to run a “real” migration with a copy of your production data.

For your information, our hadware settings and data volume is described at the end of this post.
Basically, we have about 500 Gb of documents in our repository, but this is not the most important indicator actually.

What you especially have to measure is the number of records you have in ALF_NODE table (and also maybe in ALF_TRANSACTION table). In our case:
SELECT COUNT(*) from ALF_NODE; => 962984

Indeed, during the upgrade, documents are not updated at all, but there are a lots of treatments on the database to upgrade the schema and update the meta-data. We have clearly seen that most of the time/CPU is spent at database level (Oracle for us).

Especially, we can see that most of the time is spent on these 2 treatments:

a/dbscripts/upgrade/2.2/org.alfresco.repo.domain.hibernate.dialect.AlfrescoOracle9Dialect

b/ Applying patch ‘patch.updateDmPermissions’ (Update ACLs on all DM node objects to the new 3.0 permission model).

——————
2/ Some tuning and recommendations:

2.1/ The first advice (mandatory !) is to do a “cold backup” of your source production database. That means when you will do the database export to get a copy of your data, you have to stop Alfresco application. Otherwhise, you will probably experience several unique constraint violation errors…

——

2.2/ If you experience some SQL errors during data migration, it might be “normal”:

For instance, in our case we had some errors like this:
17:09:48,034 ERROR [org.alfresco.repo.domain.schema.SchemaBootstrap] Statement execution failed:
SQL: INSERT INTO t_alf_node
(
id, version, store_id, uuid, transaction_id, node_deleted, type_qname_id, acl_id,
audit_creator, audit_created, audit_modifier, audit_modified
)
SELECT
n.id, 1, s.id, n.uuid, nstat.transaction_id, 0, q.qname_id, n.acl_id,
null, null, null, null
FROM
alf_node n
JOIN t_qnames q ON (q.qname = n.type_qname)
JOIN alf_node_status nstat ON (nstat.node_id = n.id)
JOIN t_alf_store s ON (s.protocol = nstat.protocol AND s.identifier = nstat.identifier)

This might not necessarily a big problem. Some of these errors are well know by the support and due to some bugs in the v2.x Alfresco code. If you have such problem, then contact the support directly, and they will probably be able to provide an SQL script to cleanup the source v2.x data. Of course, you will have to restart the upgrade path from scratch, and re-import the initial v2.x database copy (cleanup script should be applied on the data copy, not directly in production :-).

——

2.3/ Database tuning:

The best way to speed up these treatments (if you want to avoid a too big downtime during migration) is to do some database tuning.

We have asked the support to know what are the best practices for Oracle, and here is the feedback:

” From previous occurrences we have analyzed the Oracle performances using certain statements.

We would recommend that you recalculate the schema stats on the database which may well speed things up a little:

dbms_stats.gather_schema_stats(ownname => user, options => ‘GATHER AUTO’, estimate_percent => dbms_stats.auto_sample_size); “.

We have tested that for Oracle 10g (run a dbms_stats before running the upgrade), but it has no significant effect…

If you are using MySQL, then I think there are a lots of tuning recommendation that the support could share with you, depending
on your configuration…sorry I have no more details for you, but support will probably be able to help.

——

2.4/ JVM tuning
Another tuning we applied was to increase -Xmx to 4G (we have a 64 bits server). This clearly helps for migration, at least it prevent us from OOM during the migration.

——

2.5/ If you experience OutOfMemory during data migration, then in some case you can simply – increase heap size – and relaunch the upgrade. This is possible only if all the Schema Update database script have been succesfully applied, and that the script fail during the “patches” execution.

So basically, if you see such lines in your log files…

10:37:06,193 INFO [org.alfresco.repo.domain.schema.SchemaBootstrap] Executing database script /home/alfresco/alfresco211/tomcat/temp/Alfresco/AlfrescoSchemaUpdate-org.hibernate.dialect.Oracle9Dialect-52799.sql (Copied from classpath:alfresco/dbscripts/create/1.4/org.hibernate.dialect.Oracle9Dialect/post-create-indexes-02.sql).
10:37:06,226 INFO [org.alfresco.repo.domain.schema.SchemaBootstrap] All executed statements written to file /home/alfresco/alfresco211/tomcat/temp/Alfresco/AlfrescoSchemaUpdate-All_Statements-52800.sql.
(…)
10:37:47,789 INFO [org.alfresco.repo.admin.patch.PatchExecuter] Checking for patches to apply …
(…)
18:13:41,080 INFO [org.alfresco.repo.admin.patch.PatchExecuter] Applying patch ‘patch.updateDmPermissions’ (Update ACLs on all DM node objects to the new 3.0 permission model).
18:14:01,264 WARN [org.alfresco.repo.cache.TransactionalCache.org.alfresco.storeAndNodeIdTransactionalCache] Transactional update cache ‘org.alfresco.storeAndNodeIdTransactionalCache’ is full (10000).
18:52:15,387 ERROR [org.alfresco.repo.admin.patch.PatchExecuter] (…)

…that means you can restart the server, and the PatchExecuter will probably be able to restart the upgrade from the latest point.

——

2.6/ See next post : Upgrade path from 2.x to 3.2 : some tuning and recommendations (Part 2)

=============================
3/ Our hardware settings and volume of data:

FYI, our stack is:
– Linux server with 4CPU and 8GB of RAM (64 bits)
– Red Hat Enterprise Linux Server release 5.x
– Oracle 10g (installed on the same server as Alfresco application)
– Tomcat 6.0.18
– JDK 6 u16 x64
– JVM settings:
export JAVA_OPTS=”-Xms4G -Xmx4G -XX:NewRatio=2 -XX:PermSize=160m -XX:MaxPermSize=160m -server”
export JAVA_OPTS=” ${JAVA_OPTS} -Dalfresco.home=${ALF_HOME} -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError”

Our volume of data:

Our contentstore contains ~ 1 400 000 items (files and directories) and ~ 464Gb of documents.

SELECT MAX(ID) from ALF_NODE; => 103353578
SELECT COUNT(*) from ALF_NODE; => 962984

SELECT MAX(ID) from ALF_TRANSACTION; => 103353617
SELECT COUNT(*) from ALF_TRANSACTION; => 2540267