Hi Benjamin,
Indeed those duplicates are sure to cause problems. I would recommend
shutting down Jahia, purging the duplicates and relaunching, to see if
it solves the problem.
Regards,
Serge Huber.
[EMAIL PROTECTED] wrote:
Hi Serge!
Finally I could reproduce the exception I was mentioning a month ago.
It somehow happens that for some fields there are two same entries in
the database. Here is an excerpt of our JAHIA_FIELDS_DATA table.
*ID_JAHIA_FIELDS_DATA* *JAHIAID_JAHIA_FIELDS_DATA*
*PAGEID_JAHIA_FIELDS_DATA* *CTNID_JAHIA_FIELDS_DATA*
*FIELDDEFID_JAHIA_FIELDS_DATA* *TYPE_JAHIA_FIELDS_DATA*
*CONNECTTYPE_JAHIA_FIELDS_DATA* *VALUE_JAHIA_FIELDS_DATA*
*RANK_JAHIA_FIELDS_DATA* *RIGHTS_JAHIA_FIELDS_DATA* *VERSION_ID*
*WORKFLOW_STATE* *LANGUAGE_CODE*
10263 1 1 10043 10041 1 0 100 0 11685
0 2 shared
10263 1 1 10043 10041 1 0 100 0 11685
0 2 shared
10264 1 1 10043 10042 20 0
0 11686 0 2 shared
10264 1 1 10043 10042 20 0
0 11686 0 2 shared
10265 1 1 10043 10043 20 0
0 11687 0 2 shared
10265 1 1 10043 10043 20 0
0 11687 0 2 shared
10266 1 1 10043 10039 2 0 test 0 11688
0 2 de
10267 1 1 10043 10040 20 0
0 11689 0 2 shared
For those fields, which have two entries, we get the mentioned
exceptions. How come, that there are two same entries? I guess it is
not a normal behaviour and how can we prevent this exception, which
blocks the workflow as a page cannot be activated anymore?
Greetings,
Benjamin
Serge wrote on Fri, 13 May 2005 02:17:07 -0700
Hi Benjamin,
Do you have a reliable way of reproducing this so that we may test it
? We haven't be able to reproduce it here during our testing. Also
which JVM are you using ?
Regards,
Serge Huber.
Benjamin wrote on Wed, 11 May 2005 03:09:32 -0700 :
We are still using Jahia 4.0.5, but on heavy testing we encounter that
the workflow process is quite unstable sometimes. When looking in the
LOG files, I for instance can see an ArrayIndexOutOfBoundsException in
the ContentField.acivate(...) method.
In this loop we get this exception in the line
activeAndStagingEntryStates.remove (i);, because i has the value -1.
It seem strange anyway that the removing from the
activeAndStagingEntryStates collection is happening in the inner loop
and not in the outer loop. As you haven't changed the code in the 4.1
version it seems to work for everybody else, or could it be that there
is a bug?
// we backup all active entries that will be replaced
for (int i = 0; i < activeAndStagingEntryStates.size (); i++) {
ContentObjectEntryState actEntryState = (ContentObjectEntryState)
activeAndStagingEntryStates.get (
i);
if (actEntryState.isActive ()) {
for (int j = 0; j < stagedEntries.size (); j++) {
ContentObjectEntryState staEntryState = (ContentObjectEntryState)
stagedEntries.get (
j);
if (actEntryState.getLanguageCode ().equals (
staEntryState.getLanguageCode ())) {
// ok appollo, we catched an active entry here! we handle this..
if (versioningEnabled) {
ContentObjectEntryState backupEntryState = ContentFieldDB.getInstance
().backupDBValue (
this, actEntryState); // we backup the active version
// ok we backuped an entry of the field
if (backupEntryState != null) {
// if the entry state list is loaded, let's update it
if (versioningEntryStates != null) {
versioningEntryStates.add (backupEntryState);
}
// also we must call the changeEntryState because, like, we changed
the version or
// something hehe..
this.changeEntryState (actEntryState, backupEntryState,
jParams, stateModifContext);
}
} else {
// if versioning is not enabled, we delete the old value content!
this.deleteEntry (actEntryState);
}
// we then delete the active entry
ContentFieldDB.getInstance ().deleteDBValue (this, actEntryState);
activeAndStagingEntryStates.remove (i);
i -= 1;
}
}
}
}
Greetings,
Benjamin Papez
