Bug 833008

There's one human task process in the repo that can be safely started, the task completed, nothing goes wrong (whitespace process).
Also, the first human task of the Evaluation process, the self evaluation, does not "resist" when the instance is terminated (the task has been released at that time).
Terminating the skipTask after the test fails on the second mentioned problem also does not throw anything.

Good new is, after isolating the two tests causing second and third problem, those two problem don't show up. So it's just the creation of those group tasks that is problematic. Still, this shows that once it fails on that, it simply keeps on failing, which still is not good.

I tried to use a tip from lpetrovi - start the server with -Dfile.encoding=UTF-8 - but the results are the same. Never-the-less this seems like a good direction to be looking in.

MySQL's default encoding is platform dependent. It's independent of the JVM encoding (so -Dfile.encoding=UTF-8).

It's set in the my*.ini file if I recall correctly. On linux that file is in /etc/mysql/ but on windows no idea.

Mysql's encoding (which is used in all varchar fields) is
on linux defaulted to UTF-8
on windows it's defaulted to the OS encoding, which is windows-1252 (a € variant of Latin-1) on a Belgian computer.

mysql encoding is not to be blamed: Lukas confirmed the mysql database itself is hosted on unix/linux.

Googling the mysql error code brings this
"In 5.0, both tables must be INNODB. 5.1 (somewhat weirdly) coerces the business table to INNODB, saving us once again from our sins :-)."

http://forums.mysql.com/read.php?10,217927,217930#msg-217930

I get the same results with PostgrSQL 8.4, the exception just has a bit more info:

WARN  [org.hibernate.util.JDBCExceptionReporter] (Thread-27) SQL Error: 0, SQLState: 23503 
ERROR [org.hibernate.util.JDBCExceptionReporter] (Thread-27) Batch entry 0 insert into PeopleAssignments_PotOwners (task_id, entity_id) values ('32', 'PM') was aborted.  Call getNextException to see the cause.
WARN  [org.hibernate.util.JDBCExceptionReporter] (Thread-27) SQL Error: 0, SQLState: 23503
ERROR [org.hibernate.util.JDBCExceptionReporter] (Thread-27) ERROR: insert or update on table "peopleassignments_potowners" violates foreign key constraint "fk1ee418d2c122ed2"   Detail: Key (entity_id)=(PM) is not present in table "organizationalentity".
ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-27) Could not synchronize database state with session org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update

Further tests revealed that:
1) it does not matter whether UserGroupCallback is used or not
2) mssql2008r2 fails too (not a surprise) this time with 
WARN  [org.hibernate.util.JDBCExceptionReporter] (Thread-27) SQL Error: 547, SQLState: 23000
ERROR [org.hibernate.util.JDBCExceptionReporter] (Thread-27) The INSERT statement conflicted with the FOREIGN KEY constraint "FK1EE418D2C122ED2". The conflict occurred in database "dballo00", table "dbo.OrganizationalEntity", column 'id'.
ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-27) Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not insert collection: [org.jbpm.task.Task.peopleAssignments.potentialOwners#4]
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
...
	at org.jbpm.task.service.persistence.TaskLocalTransactionManager.commit(TaskLocalTransactionManager.java:55)
	at org.jbpm.task.service.persistence.TaskPersistenceManager.endTransaction(TaskPersistenceManager.java:94)
...
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the FOREIGN KEY constraint "FK1EE418D2C122ED2". The conflict occurred in database "dballo00", table "dbo.OrganizationalEntity", column 'id'.
	at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:197)
...
	at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
	at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:46)
	at org.hibernate.persister.collection.AbstractCollectionPersister.recreate(AbstractCollectionPersister.java:1168)
	... 18 more

ERROR [org.jbpm.process.workitem.wsht.AsyncWSHumanTaskHandler] (Thread-44) Tue Jun 19 09:11:33 EDT 2012: Error when creating task on task server for work item id 4. Error reported by task server: Command AddTaskRequest faild due to Could not commit transaction. Please contact task server administrator.
java.lang.RuntimeException: Command AddTaskRequest faild due to Could not commit transaction. Please contact task server administrator.

This last exception, is it possible this is done during initialization?  It seems it's trying to register the group now, but note you shouldn't be doing this more than once.  So this exception now seems to indicate the group is already there, so can't be added again.

I've been able to reproduce the exact same stack trace on a linux machine. 

It very much looks like the bug was caused by the fact that the underlying datasource for the human-task component had not been filled with the needed user and group information. (This is how I reproduced the bug on a linux machine.)

Furthermore, I've run a number of different tests (both unit and via a running BRMS server) and I also debugged a large part of the code for this (remote java debugging) -- all on the windows machine in question, which generated this bug. None of these things have turned up any surprising errors. 

I've looked at lots of different possible causes (upper/lowercase windows issues, clock resolution, CR/LF's, etc.) and none matched the stack trace. 

After discussing this with a number of people, I am strongly inclined to call this not a bug -- just a false positive that happened, as they sometimes do.