From: patrickvanamstel <do-...@jb...> - 2006-05-19 09:57:50
|
The problem is fixed by setting the ehcache to a more conservative objects in memory setting View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3944861#3944861 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3944861 |
From: patrickvanamstel <do-...@jb...> - 2006-05-19 10:52:16
|
Solution does not seem to work. So i was a bit to soon. So ony tips would be welcome. Is there maybe a hibernate setting i can use?? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3944872#3944872 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3944872 |
From: kukeltje <do-...@jb...> - 2006-05-19 15:49:47
|
can you profile the application and see what takes up the memory? btw, how many variables are you using in your processdefinition? I never get any higher than 20-25 in development fase and 10 if I change to using a dossier for most business info View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3944942#3944942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3944942 |
From: patrickvanamstel <do-...@jb...> - 2006-05-30 06:15:58
|
Thank you for your reaction. Back from holiday i'm continueing my quest for variables and memory usage/ I'm not used using profiling tools. But in short i'm doing the programatic fork / join. In the fork i create variable's which are byte arrays. final ExecutionContext newExecutionContext = new ExecutionContext(newToken); //newExecutionContext.getContextInstance().createVariable(Constants.XML_DOCUMENT_STRING,baos.toByteArray(), newToken); newExecutionContext.getContextInstance().createVariable(Constants.XML_DOCUMENT_STRING,baos.toByteArray(), newToken); newExecutionContext.getJbpmContext().save(executionContext.getProcessInstance()); There could be 10.000 variables created. So it is important that the memory usage is as low as possible. Is it possible to commit the hiberbate transaction inbetween. Cause after the last line a commit would be fine by me. The biggist question ofcourse is. How does the transaction influence the memory usage. And when are the variables persisted. Maybe jbpm is not the proper java framework for processing this, but it seemed very usefull. So here some context Process in short is: One file -> validate Split - file -> (10 till 100.000) If failure user interaction Otherwise -> continue till done Report to customer Report to calculations The user interaction will only happen when the instream fails. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3947528#3947528 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3947528 |
From: kukeltje <do-...@jb...> - 2006-05-30 06:51:54
|
For storing this kind/amount of data we (the company I work for) do not use jbpm variables. We store the data externally and store a reference to it in a jbpm variable. The number of variables per processinstance in development can grow to 20-30 but eventually it almost never exceeds 10. Is this a possible solution? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3947536#3947536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3947536 |
From: patrickvanamstel <do-...@jb...> - 2006-05-30 10:09:50
|
If that is the way to go i must consider it. Because i do not want to go against the flow. But actually i solved the problem by adding to line of code to the persistance code. DbPersistenceService.java // added session.flush(); session.clear(); // before transaction.commit(); This seems to help my out of memory. But i havent testet it to death yet. But wat i want to do next is off load the variables to a queue and process it from there. But now i'm first trying to get a grip on the logging. (Now posting a new post about the processInstance id) thx Patrick View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3947578#3947578 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3947578 |