Existen ciertos falsos mitos sobre la performance de jBPM. Estos mitos informáticos pueden hacer que un cliente descarte una tecnología sin siquiera haber tenido una evaluación real de los beneficios de su uso. Joram Barrez ha salido, como los cazadores de mitos, a refutar la fama de mala performance de jBPM con una muy interesante presentación: Some real-life jBPM action: PoC jBPM Orchestration. Esta presentación ha causado una muy buena impresión en el mismísimo creador de jBPM y ha dado pie a una interesante discusión en el blog de Tom Bayens y a un nuevo post de Joram, con un benchmark más exhaustivo: Short jBPM Performance Showdown

Entre las optimizaciones que menciona Joram destacan:

• Deshabilitar el logging a JBPM_LOG
  

jBPM tiene por defecto muchísimo logging. Simplemente deshabilitando el servicio de logging de jBPM permitió ejecutar 250.000 procesos más en una hora, eso significa que los procesos se ejecutan 3 veces más rápido que con el logging habilitado.
• configurar Log4j a nivel ERROR
  

y así reducir aún más las entradas de los logs.
• poner la propiedad "show_sql" en false.

Con esta propiedad configurada en true, Hibernate imprime en los logs TODAS sus queries SQL.
• Según Joram la mejor ayuda a la performance de jBPM es configurar correctamente la cache de Hibernate.
  

jBPM ejecuta una gran cantidad de queries, y muchas de ellas pueden ser cacheadas sin ningún problema. El 90% del tiempo jBPM está haciendo tareas de Hibernate.

Por supuesto que todo esto es solo para cuando se quiere exprimir al máximo hasta el último ciclo del procesador. Porque en mi opinión, para el uso estándar de jBPM la configuración por defecto es lo suficientemente buena.

Contribuyendo al ruido de la red:

ascandroli@gualicho:~$ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
115 mvn
102 cd
92 sudo
36 exit
32 ll
21 history
20 .
18 ssh
12 svn
10 ps


ascandroli@hermes:~$ history | awk '{a[$2]++}END{for(i in a){print a[i] " "i}}' | sort -rn | head
122 cd
74 mvn
53 ll
41 exit
31 sudo
25 .
21 svn
19 cg
14 ps
11 ssh


Que dicen estos comandos de mi:

• mvn: ;-)


• . : que tengo demasiados scripts para cambiar las variables de entorno.


• exit: que cierro los tabs de las consolas desde la misma linea de comandos.


• history: que no me acuerdo de memoria los comandos para usar javarebel o para hacer debug con jetty y maven.


• ps: que el tomcat se cuelga demasiado y que tengo que ir a matarlo manualmente.

He abogado por el uso de Git en varias oportunidades. Lo he intentado usar en varios proyectos, pero solo lo he logrado en mis propios proyectos o en proyectos que no son Java.

¿Por qué solo en proyectos que no son Java?

Porque el programador Java medio tiene un extraño rechazo visceral por las herramientas de línea de comandos y lamentablemente Git todavía no está integrado ni a Eclipse, ni a NetBeans ni a IntelliJ IDEA.
Lo curioso es que ahora que los chicos "cool" del barrio planean mudarse a Git yo recibo más consultas en un día que nunca.

Así que si sos capaz de superar el trauma emocional que implica abandonar el mundo de las ventanas y querés probar de que están hablando nuestros vecinos más ágiles, acá va mi arenga:

La GRAN GRAN ventaja de Git es el "working tree" (árbol de trabajo), el repositorio local al PC del programador. Todos los "commits" suceden en local y no se suben al repositorio hasta que no se hace un "push". Esta copia local del repositorio, permite hacer branches en local sin siquiera la necesidad de cambiar de directorio o hacer un nuevo checkout. Gracias a esto yo puedo estar trabajando un mi trunk local, crear un branch para trabajar en un parche urgente, subir todos los cambios del branch al repositorio central y volver a trabajar en mi trunk, todo sin cambiar del proyecto abierto en el Eclipse. Otra característica de Git difícil de digerir para los usuarios de Subversion es que Git jamás se confunde en un merge, JAMÁS!. Y créanme, he intentando sin éxito "hacerle pisar el palito", porque me costaba creerlo.

Para adentrarse en el mundo de Git, en realidad es preferible empezar usando Cogito, Cogito es meramente una interfaz de Git, que ha sido especialmente adaptada para el hombre de a pie. Cogito es completamente compatible con GIT (aunque hay que seguir ciertas convenciones) y hace que la transición SVN > Git sea más amena.
Por ejemplo el comando de Cogito:

$ cg-init

equivale a los comandos de Git:

$ git init && git add . && git commit

Incluso cg-init, por defecto, ignora los .svn, cosa que Git no hace.

Lo más fácil para los que recién comienzan, es empezar imitando el flujo de trabajo que tiene Subversion, que aunque limita algunas de las carácterísticas de Git, es suficiente como para un primer acercamiento. Para esto basta con crear un repositorio central contra el que trabajar. Este tipo de repositorios centrales se llaman "bare". Un repositorio "bare" es un repositorio que no es una copia activa, que no tienen un árbol de trabajo (working tree), es decir un repositorio al que nadie hace un cg-commit (tener en cuenta que svn commit no es conceptualmente igual a cg-commit)
La mayoría de los repositorios Git que se ofrecen via web (ej: github), son de este tipo de repositorios "bare".

Crear un repositorio "bare" en un servidor es tan fácil como:

$ cg-admin-setuprepo -g gitpushers /srv/git/myproyecto.git

El valor indicado en "-g" es el groupid de los usuarios que tienen permisos de "push"

Luego en local en el directorio donde esté el proyecto que se quiera subir:

$ cg-init (inicializa la copia local, ignora los .svn en caso de que existan, así que se puede usar Cogito y Subversion a la misma vez)

$ cg-branch-add origin git+ssh://git.amneris.es/srv/git/myproyecto.git (le indica a la copia local que en realidad es un branch del repositorio git.amneris.es/srv/git/myproyecto.git, el nombre "origin" es una convención de Cogito)

$ cg-push (sube la copia a local al repositorio central)

Cada usuario que se quiera bajar una copia del proyecto (svn co) tendrá que ejecutar:

$ cg-clone git+ssh://git.amneris.es/srv/git/myproyecto.git

para bajar cambios del repositorio:

$ cg-update

para hacer commit de las modificaciones

$ cg-commit -m "No olvidarse de comentar todos los checkins aunque sean locales"

y cuando ya tengan todo listo y estén preparados para subir sus cambios al repo central:
Los invito a probarlo, vale la pena el esfuerzo, aunque sea simplemente para conocer otro paradigma de SCM.

PS: Lo que daría yo por tener un 1% del poder de influencia que tiene DHH y 37signals. La verdad es que a veces siento que mis opiniones provocan una reacción en la dirección opuesta.
Algo así como que ahora todos los lectores de este post abandonan el uso de Subversion pero en dirección CVS :(