Problem to redeploy ESBRules application without shutdown Jb

[claudio_br]

Hi,

I am using JBoss AS 4.2.1.GA and ESB 4.2MR3.
When I do the first deploy in JBoss, the content based routing (with rules) workout, but if I do a second deploy without shutdown JBoss AS, my application doesn´t workout.

My log server at first deploy (workout)

2007-08-06 15:04:32,875 INFO [STDOUT] The Rules will be next action
2007-08-06 15:04:32,875 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] executing processor 3
2007-08-06 15:04:32,875 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Going to hash the rule: Empire.drl
2007-08-06 15:04:32,875 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Reading ruleSet from file=Empire.drl
2007-08-06 15:04:32,890 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Going to read the rule: Empire.drl
2007-08-06 15:04:33,468 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@2925e{ url=null ,addedOrder=0}
2007-08-06 15:04:33,546 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@8dd37d{ url=null ,addedOrder=0}
2007-08-06 15:04:33,546 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@137d9c8{ url=null ,addedOrder=0}
2007-08-06 15:04:34,281 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@150a1ac{ url=null ,addedOrder=0}
2007-08-06 15:04:34,281 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@a64adb{ url=null ,addedOrder=0}
2007-08-06 15:04:34,281 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@17ca589{ url=null ,addedOrder=0}
2007-08-06 15:04:34,281 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@5805bc{ url=null ,addedOrder=0}
2007-08-06 15:04:34,281 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@e07ad7{ url=null ,addedOrder=0}
2007-08-06 15:04:34,687 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@1c620d9{ url=null ,addedOrder=0}
2007-08-06 15:04:34,718 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@6be2c6{ url=null ,addedOrder=0}
2007-08-06 15:04:34,718 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@f56dcc{ url=null ,addedOrder=0}
2007-08-06 15:04:34,718 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@a19277{ url=null ,addedOrder=0}
2007-08-06 15:04:34,718 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@dc91e2, cl=org.jboss.mx.loading.HeirarchicalLoaderRepository3$CacheClassLoader@196dc99{ url=null ,addedOrder=0}
2007-08-06 15:04:35,046 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Obtained message=message: [ JAVA_SERIALIZED ]
[ header: [ To: EPR: PortReference < <wsa:Address jms://localhost/queue/maplink_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/> >, From: null, ReplyTo: null, FaultTo: null, Action: null, MessageID: 2035924c-bd7e-4e17-a104-4ee7f9ee63f0, RelatesTo: null ]
context: [ null ]
body: [ objects: {Comando=com.buscape.bean.Comando valor: AtualizaXYEndereco, Resposta=
CoordenanadaXY ->
CoordenadaX: '-46.64424'
CoordenadaY: '-23.57133', Parametros=[Ljava.lang.Object;@8e2b14} ]
fault: [ null, null ]
attachments: [ Named:{}, Unnamed:[] ]
properties: [ {org.jboss.soa.esb.message.time.dod=Mon Aug 06 15:04:25 BRT 2007, org.jboss.soa.esb.message.transport.type=JMS, org.jboss.soa.esb.message.source=PortReference < jms://localhost/queue/maplink_esb >, org.jboss.soa.esb.message.time.dob=Mon Aug 06 15:04:25 BRT 2007} ] ] with ruleSet=Empire.drl
2007-08-06 15:04:35,062 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Fire the JBossRules Engine
2007-08-06 15:04:35,062 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Outgoing Destinations: [AtualizaXYEndereco]
2007-08-06 15:04:35,078 DEBUG [org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl] Going to query the registry for name pattern [AtualizaXYEndereco]
2007-08-06 15:04:35,078 DEBUG [org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl] Service name: AtualizaXYEndereco
2007-08-06 15:04:35,078 DEBUG [org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl] Description: null
2007-08-06 15:04:35,078 DEBUG [org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl] Key id: FBC580D0-41F5-11DC-80D0-D520520B1AA5
2007-08-06 15:04:35,125 DEBUG [org.jboss.internal.soa.esb.rosetta.pooling.JmsConnectionPool] Returning session, poolsize=9, maxsize=20, number of pools=2
2007-08-06 15:04:35,125 DEBUG [org.jboss.jms.server.security.SecurityMetadataStore] No SecurityMetadadata was available for atualiza_x_y_endereco_esb, using default security config
2007-08-06 15:04:35,125 DEBUG [org.jboss.jms.client.container.ClosedInterceptor] ClosedInterceptor.ClientProducerDelegate[-1] closed
2007-08-06 15:04:35,140 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] pipeline process for message
2007-08-06 15:04:35,140 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] executing processor 0
2007-08-06 15:04:35,140 WARN [com.buscape.esb.AtualizaXYEnderecoEsb] AtualizaXYEndereco(logradouro: Av Paulista, numero: 1, cidade: São Paulo, uf: SP, cep: 05050000,4,
EnderecoPontoComercial ->
Nome: 'Unidade Paulista'
Ativo: 'true'
Publicavel: 'false'
Principal: 'true'
PossuiEstac:'false'
PossuiXY: 'true
Endereco ->
Id: 'null'
Logradouro: 'Av Paulista'
Numero: '1'
Complemento:'12º andar'
Cep: '05050000'
Pais: 'Brasil'
Uf: 'SP'
Cidade: 'São Paulo'
Bairro: 'Bela Vistanull
Collection Telefones: [])
2007-08-06 15:04:35,140 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] executing processor 1
2007-08-06 15:04:51,625 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - first pass <Seg, 6 Ago 2007 15:04:51>
2007-08-06 15:04:51,625 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] StatusModule: first pass
2007-08-06 15:04:51,625 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass
2007-08-06 15:04:51,625 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass
2007-08-06 15:05:01,625 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - second pass <Seg, 6 Ago 2007 15:05:01>
2007-08-06 15:05:01,625 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] AtomicActionRecoveryModule: Second pass
2007-08-06 15:05:01,625 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass
2007-08-06 15:05:01,625 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass

My log server at second deploy (doesn´t workout)

2007-08-06 15:06:31,562 INFO [STDOUT] The Rules will be next action
2007-08-06 15:06:31,562 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] executing processor 3
2007-08-06 15:06:31,562 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Going to hash the rule: Empire.drl
2007-08-06 15:06:31,562 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Obtained message=message: [ JAVA_SERIALIZED ]
[ header: [ To: EPR: PortReference < <wsa:Address jms://localhost/queue/maplink_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/> >, From: null, ReplyTo: null, FaultTo: null, Action: null, MessageID: 5af9c82d-36ca-4f45-8d56-e1a5f59cef8b, RelatesTo: null ]
context: [ null ]
body: [ objects: {Comando=com.buscape.bean.Comando valor: AtualizaXYEndereco, Resposta=
CoordenanadaXY ->
CoordenadaX: '-46.64424'
CoordenadaY: '-23.57133', Parametros=[Ljava.lang.Object;@187828f} ]
fault: [ null, null ]
attachments: [ Named:{}, Unnamed:[] ]
properties: [ {org.jboss.soa.esb.message.time.dod=Mon Aug 06 15:06:28 BRT 2007, org.jboss.soa.esb.message.transport.type=JMS, org.jboss.soa.esb.message.source=PortReference < jms://localhost/queue/maplink_esb >, org.jboss.soa.esb.message.time.dob=Mon Aug 06 15:06:28 BRT 2007} ] ] with ruleSet=Empire.drl
2007-08-06 15:06:31,562 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Fire the JBossRules Engine
2007-08-06 15:06:31,562 DEBUG [org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter] Outgoing Destinations: []

The Empire.drl (rules)

package com.buscape;

import org.jboss.soa.esb.message.Message;
import org.jboss.soa.esb.message.format.MessageType;
import com.buscape.bean.Comando;

#declare any global variables here
global java.util.List destinations;

rule "AtualizaXYEndereco"
 when
 Comando(valor == "AtualizaXYEndereco")
 then
 destinations.add("AtualizaXYEndereco");
end

rule "AtualizaXYCep"
 when
 Comando(valor == "AtualizaXYCep")
 then
 destinations.add("AtualizaXYCep");
end

jboss-esb.xml

<action name="ContentBasedRouter" class="org.jboss.soa.esb.actions.ContentBasedRouter" >
 <property name="ruleSet" value="Empire.drl" />
 <property name="ruleReload" value="true" />
 <property name="destinations">
 <route-to destination-name="AtualizaXYEndereco" service-category="Empresa" service-name="AtualizaXYEndereco" />
 <route-to destination-name="AtualizaXYCep" service-category="Empresa" service-name="AtualizaXYCep" />
 </property>
 <property name="object-paths">
 <object-path path="body.Comando" />
 </property>
</action>

In first and second deploys I run the same junit, but only first deploy workout. If I shutdown the server, my application workout.
From server log, you can note the Comando´s value is AtualizaXYEndereco in both case

Is it a problem with rules?
Thanks

[kurtstam]

Looks like a known issue?

http://jira.jboss.com/jira/browse/JBESB-704

[claudio_br]

No Kurt,

I haven´t looked this jira.
The ESB with this problem I can´t use JRules (content based routing).
Can the jboss team jboss prioritize the solution of this problem?
Thanks.

[marklittle]

If you think this is a new issue then please create a JIRA in the 4.2.1 timeframe. If it's 704, then it'll be fixed in 4.2.1: earlier if we have the time.

[claudio_br]

It seem to be same problem of jira 704.
Is there any work around to resolve this problem?
When will go out version 4.2.1?
Thanks

[marklittle]

No workaround known by us at the moment because we haven't had a chance to look at it. 4.2.1 is due out end of September.

If you want to take a look at the code yourself and suggest fixes, we'll try to help as much as we can.

[burrsutter]

Are you deploying with a .esb archive? Exploded?

Perhaps having a .esb that is exploded in the deploy directory of the in the jboss-esb.xml

the quickstart called fun_cbr illustrates how to make changes to the routing rules "on the fly".

Does any of this help?

[claudio_br]

Burr, I deploy an .esb archive, but the problem persist.

To resolve this problem, you can force update of ruleBases in org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter in each redeploy.
There is 2 workarounds for this

First workaround:

Add a comment in drl file (for example #version 1) and a each redeploy change the comment to #version 2, #version 3 ... this will force update the ruleBases and the content based routing workout after redeploy.

Second workaround:

Change org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter and add this code in:

before

RuleBase ruleBase = ruleBases.get(ruleSet);

if (ruleBase == null || isRulesChanged)

after

RuleBase ruleBase = ruleBases.get(ruleSet);

// Force isRulesChanged = true
isRulesChanged = true;

if (ruleBase == null || isRulesChanged)

But second workaround will be cause extra overhead, because will force update of ruleBase in all message routing.
The first workaround is better.

Someone has a better solution for this?
Thanks.

[burrsutter]

Try the exploded .esb (see the bpm_orchestration2 as an example) deployment option.

They just touch the .drl.

I think the strategy of adding a comment with the version number seems like a reasonable approach for the short-term.

We were purposefully trying to cache the rules so that we weren't re-reading the .drl file with every new message.

[claudio_br]

Burr,

Could the jboss team change this jira to ESB 4.2.GA?
Thanks.

[marklittle]

That's up to the project lead, who's on vacation. I step back into that slot when he's away. At the moment the answer is no. If we have time we'll certainly look at pushing this (and as many other things as we can) into 4.2. If you haven't already done so, cast a vote on the issue because we'll use those as a way of prioritizing things from 4.2.1 into 4.2 when and if we have time.

[claudio_br]

Ok Mark,

Thanks