Delete record from table ACT_GE_BYTEARRAY

Hi
My problem is growing size of table ACT_GE_BYTEARRAY and i want to delete some records from it, who can help me?

Hi rasoolavazeh,

Try to find out why BYTEARRAY is growing.
My guess will be variables from history serialized by java serialization.
If that is the case purge history, decrease history level, reduce variables size.

Regards
Martin

When i use Manually Deleting History HI tables are cleand but act_ge_bytearray does not change,

note: can i use 0 for setCleanInstancesEndedAfterNumberOfDays() method in configuration?

Is the grow caused by history?

maybe, i want to know why does not delete records on act_ge_bytearray when clean history.

Hey @rasoolavazeh,

Which version are you using?

Instead of using the deleteWithRelatedData we would suggest using the methods from the new BatchDeleteQuery

e.g.

Calendar cal = new GregorianCalendar();
 cal.set(Calendar.YEAR, cal.get(Calendar.YEAR) - 1);
 historyService.createHistoricProcessInstanceQuery()
   .finishedBefore(cal.getTime())
   .deleteSequentiallyUsingBatch(batchSize, batchName);

Cheers,
Filip

I faced the same issue. And i follow the History · Flowable Open Source Documentation to add the manually clean job. But can’t clean the table ACT_GE_BYTEARRAY. My version is 6.7.0

Above is our DB detail

With the delete query there was indeed a bug before wrt historical variables, we’ve fixed this in the upcoming 6.8.0 release.

Update:
we found we use this method to set variables and variables are set it to the below DB table.
org.flowable.variable.api.delegate.VariableScope#setVariable(java.lang.String, java.lang.Object) .
So my question is there any method I can clean those not used variables ?

@joram So, you mean this is because of historical variables bugs? I mean if everything is correct. Those variables will be cleaned after we do ” History Cleaning“?

No, I mean that in your version (6.7.0) there is a bug where historical variables are not removed when doing the deleteSequentiallyUsingBatch (which i assume you have from the screenshot you posted as the row starts with hist.var-). In the upcoming 6.8.0 (i.e. not released yet) this is fixed. For now, you’ll need a manual deletion of those ‘dangling’ historical variables.

@joram Thank you for your response. Do you have any method or hints that I can manual delete those variables?

Not through an API. You’d need to write a custom Command and execute it through ManagementService#executeCommand. In it, you can use the HistoricVariableInstanceEntityManager to delete the variables (which will delete the byte arrays).