[JBoss JIRA] Created: (JBESB-1540) WebService invocation is sometimes handled by CoyoteInvoker belonging to undeployed package
by Jiri Pechanec (JIRA)
WebService invocation is sometimes handled by CoyoteInvoker belonging to undeployed package
-------------------------------------------------------------------------------------------
Key: JBESB-1540
URL: http://jira.jboss.com/jira/browse/JBESB-1540
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.2.1
Reporter: Jiri Pechanec
Assigned To: Kevin Conner
Priority: Minor
Attachments: server.log.gz
There were multiple packages deployed/undeployed in the test. The deployment of Quickstart_webservice_mtom.esb is started on line 413471. This package starts coyote invoker with hashCode 17a4c54 at the line 413681. The undeploymetn of this package starts on line 414408. The CoyoteInvoker with the given hashCode is stopped at line 414457.
The Quickstart_webservice_wsa.esb package deployment starts at line 414599.
The CoyotInvoker with hashCode d93db8 is started at line 414806.
Then the test message is sent via HTTP/SOAP and this request fails on line 515535 because it was served by the CoyoteInvoker with hashCode 17a4c54 so the one that belongs to previously undeployed package.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBESB-2192) [AbstractFileGateway] Composer <LocalFileMessageComposer> Failed. MessageDeliverException: Invalid File payload. File 'C:\... .esbWorking' doesn't exist.
by Douglas Zanatta Ulian (JIRA)
[AbstractFileGateway] Composer <LocalFileMessageComposer> Failed. MessageDeliverException: Invalid File payload. File 'C:\... .esbWorking' doesn't exist.
---------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBESB-2192
URL: https://jira.jboss.org/jira/browse/JBESB-2192
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.4 CP1
Environment: Windows XP SP3, JBoss AS 4.2.2.GA
Reporter: Douglas Zanatta Ulian
I'm working on an integration project where ESB is responsible for:
1: picking up XML message files in a remote host using an ftp-provider and writing them to a local directory.
2: loading each file from the local dir using fs-provider,
3: validating its XML message,
4: consuming the message using hibernate,
5: creating a result message to be returned to the sender,
6: writing it to a success/error directory,
7: loading the result message file using fs-provider,
8: sending the return info through a web service.
The problem seems to be on step 7, when multiple "return message files" are placed on the dir to be sent back to the sender, after working well with a couple of files I get the following exception:
2008-11-13 16:17:11,154 ERROR [org.jboss.soa.esb.listeners.gateway.AbstractFileGateway] Composer <org.jboss.soa.esb.listeners.gateway.LocalFileMessageComposer> Failed.
org.jboss.soa.esb.listeners.message.MessageDeliverException: Invalid File payload. File 'C:\message\loja\ok\9844_MsgUnidade_13112008_35501.msg.esbWorking' doesn't exist.
at org.jboss.soa.esb.listeners.gateway.LocalFileMessageComposer.compose(LocalFileMessageComposer.java:63)
at org.jboss.soa.esb.listeners.gateway.LocalFileMessageComposer.compose(LocalFileMessageComposer.java:44)
at org.jboss.soa.esb.listeners.gateway.AbstractFileGateway.onSchedule(AbstractFileGateway.java:156)
at org.jboss.soa.esb.schedule.ScheduleProvider$ESBScheduledJob.execute(ScheduleProvider.java:227)
at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Although the exception is raised, the process is completed and step 8 is executed, making it looks like there are two threads working on the same file, where one of them completes the entire pipeline while the other fails on step 7... though I've configured it to work with a single thread!
my jboss-esb.xml looks like this:
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml..." parameterReloadSecs="5">
<providers>
<ftp-provider name="FTPprovider" hostname="${caravelas.ftp}">
<ftp-bus busid="helloFTPChannel" >
<ftp-message-filter
username="caravelas"
password="colombo"
passive="false"
directory="${caravelas.ftp.directory}"
input-suffix=".msg"
work-suffix=".esbWorking"
post-delete="false"
post-suffix=".COMPLETE"
error-delete="false"
error-suffix=".HAS_ERROR"/>
</ftp-bus>
</ftp-provider>
<fs-provider name="FSprovider">
<fs-bus busid="SucessoFileChannel" >
<fs-message-filter
directory="${caravelas.message.ok}"
input-suffix=".msg"
work-suffix=".esbWorking"
post-delete="false"
post-directory="${caravelas.message.ok}"
post-suffix=".sentToEsb"
error-delete="false"
error-directory="${caravelas.message.ok}"
error-suffix=".IN_ERROR"
/>
</fs-bus>
<fs-bus busid="ErroFileChannel" >
<fs-message-filter
directory="${caravelas.message.erro}"
input-suffix=".msg"
work-suffix=".esbWorking"
post-delete="false"
post-directory="${caravelas.message.erro}"
post-suffix=".sentToEsb"
error-delete="false"
error-directory="${caravelas.message.erro}"
error-suffix=".IN_ERROR"
/>
</fs-bus>
</fs-provider>
<jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
<jms-bus busid="quickstartEsbChannel">
<jms-message-filter dest-type="QUEUE" dest-name="queue/B"/>
</jms-bus>
<jms-bus busid="Business_Rules_ClientePFisica">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorClientePFisicaService"/>
</jms-bus>
<jms-bus busid="Business_Rules_Linha">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorLinhaService"/>
</jms-bus>
<jms-bus busid="Business_Rules_Familia">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorFamiliaService"/>
</jms-bus>
<jms-bus busid="Business_Rules_Unidade">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ConsumidorUnidadeService"/>
</jms-bus>
<jms-bus busid="Queue_ERRO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/ERRO" />
</jms-bus>
<jms-bus busid="Queue_SUCESSO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/SUCESSO" />
</jms-bus>
<jms-bus busid="Queue_RETORNO_SUCESSO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/RetornoSucesso"/>
</jms-bus>
<jms-bus busid="Queue_RETORNO_ERRO">
<jms-message-filter dest-type="QUEUE" dest-name="queue/RetornoErro"/>
</jms-bus>
</jms-provider>
<schedule-provider name="cronExample">
<cron-schedule scheduleid="cron-schedule" cronExpression="0/5 * * * * ?"/>
</schedule-provider>
</providers>
<services>
<service category="myCategory" name="myFileListener" description="Hello World File Action (esb listener)" >
<listeners>
<ftp-listener name="FtpGateway" busidref="helloFTPChannel" is-gateway="true" scheduleidref="cron-schedule" />
<jms-listener name="helloWorldFileAction" busidref="quickstartEsbChannel" />
</listeners>
<actions>
<action name="ValidaMensagem" class="com.colombo.esb.action.ValidaMensagem"/>
<action name="ContentBasedRouter" class="org.jboss.soa.esb.actions.ContentBasedRouter">
<property name="ruleSet" value="rotas.drl" />
<property name="ruleReload" value="true" />
<property name="destinations">
<route-to destination-name="ConsumidorClientePFisicaService" service-category="ConsumidorServices" service-name="ConsumidorClientePFisicaService" />
<route-to destination-name="ConsumidorLinhaService" service-category="ConsumidorServices" service-name="ConsumidorLinhaService"/>
<route-to destination-name="ConsumidorFamiliaService" service-category="ConsumidorServices" service-name="ConsumidorFamiliaService" />
<route-to destination-name="ConsumidorUnidadeService" service-category="ConsumidorServices" service-name="ConsumidorUnidadeService" />
</property>
<property name="object-paths">
<object-path esb="body.mensagem_tipo" />
</property>
</action>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorClientePFisicaService" description="Consumidor de ClientePFisica">
<listeners>
<jms-listener name="Business_Rules_ClientePFisica" busidref="Business_Rules_ClientePFisica"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorClientePFisica" class="com.colombo.esb.action.ConsumidorClientePFisica"/>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorLinhaService" description="Consumidor de Linha">
<listeners>
<jms-listener name="Business_Rules_Linha" busidref="Business_Rules_Linha"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorLinha" class="com.colombo.esb.action.ConsumidorLinha"/>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorFamiliaService" description="Consumidor de Familia">
<listeners>
<jms-listener name="Business_Rules_Familia" busidref="Business_Rules_Familia"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorFamilia" class="com.colombo.esb.action.ConsumidorFamilia"/>
</actions>
</service>
<service category="ConsumidorServices" name="ConsumidorUnidadeService" description="Consumidor de Unidade">
<listeners>
<jms-listener name="Business_Rules_Unidade" busidref="Business_Rules_Unidade"/>
</listeners>
<actions mep="OneWay">
<action name="ConsumidorUnidade" class="com.colombo.esb.action.ConsumidorUnidade"/>
</actions>
</service>
<service category="controle" name="Erro" description="gera msg erro">
<listeners>
<jms-listener name="Queue_ERRO" busidref="Queue_ERRO" is-gateway="false"/>
</listeners>
<actions mep="OneWay">
<action name="ErroAction" class="com.colombo.esb.action.ErroAction">
<property name="directory" value="${caravelas.message.erro}"/>
</action>
</actions>
</service>
<service category="controle" name="Sucesso" description="gera msg Sucesso">
<listeners>
<jms-listener name="Queue_SUCESSO" busidref="Queue_SUCESSO" is-gateway="false"/>
</listeners>
<actions mep="OneWay">
<action name="SucessoAction" class="com.colombo.esb.action.SucessoAction">
<property name="directory" value="${caravelas.message.ok}"/>
</action>
</actions>
</service>
<service category="resposta" name="RetornoSucesso" description="gera Retorno Sucesso">
<listeners>
<fs-listener name="SucessoGateway" busidref="SucessoFileChannel" is-gateway="true" poll-frequency-seconds="10"/>
<jms-listener name="Queue_RETORNO" busidref="Queue_RETORNO_SUCESSO"/>
</listeners>
<actions mep="OneWay">
<action name="geraRetorno" class="com.colombo.esb.action.GeraRetornoMatriz" />
</actions>
</service>
<service category="resposta" name="RetornoErro" description="gera Retorno Erro">
<listeners>
<fs-listener name="ErroGateway" busidref="ErroFileChannel" is-gateway="true" poll-frequency-seconds="10"/>
<jms-listener name="Queue_RETORNO" busidref="Queue_RETORNO_ERRO"/>
</listeners>
<actions mep="OneWay">
<action name="geraRetorno" class="com.colombo.esb.action.GeraRetornoMatriz" />
</actions>
</service>
</services>
</jbossesb>
and we're using a "-service.xml" file to load the properties containing dir paths and ftp info, it looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.varia.property.SystemPropertiesService" name="jboss.util:type=Service,name=SystemProperties">
<attribute name="Properties">
caravelas.ftp=100.1.1.137
caravelas.ftp.directory=/home/caravelas/ftp/message/out/001
caravelas.message.ok=C:/message/loja/ok
caravelas.message.erro=c:/message/loja/erro
</attribute>
</mbean>
</server>
Please, let me know if any other information is needed.
Douglas
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBESB-1710) Documentation of Standalone mode in Quickstarts is confusing
by Tom Cunningham (JIRA)
Documentation of Standalone mode in Quickstarts is confusing
------------------------------------------------------------
Key: JBESB-1710
URL: http://jira.jboss.com/jira/browse/JBESB-1710
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation, Examples
Affects Versions: 4.2.1 CP2
Reporter: Tom Cunningham
In the readme.txt of every QuickStart, we document how to run in standalone mode. Do we really want to do this? Standalone mode seems like an edge case that we support, and listing it in every QS readme.txt is confusing to first time users (see forum post reference). Maybe we should have a standalone guide that describes how to run QS's in standalone mode, and focus the QS readmes on the most common method of running the QS's (running in ESB server or JBossAS+ESB).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 4 months
[JBoss JIRA] Created: (JBESB-1909) JmsConnectionPool overflows sometimes with JBossMQ
by Pavel Kadlec (JIRA)
JmsConnectionPool overflows sometimes with JBossMQ
--------------------------------------------------
Key: JBESB-1909
URL: https://jira.jboss.org/jira/browse/JBESB-1909
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.3
Environment: JBossAS-4.2.2.GA with JBossMQ
Reporter: Pavel Kadlec
The core reason is that JBossMQ's XAConnectionFactory.createSession always creates XASession (is always transacted and with SESSION_TRANSACTED acknowledgement mode), but JBossMessaging's XAConnectionFactory.createSession creates non-xa Session (transacted or non-transacted and with customized acknowledgement mode). The JmsConnectionPool is intended to be used with JBossMessaging behaviour only.
The overflow occurs when caller thread associated with *NO* transaction sends esb message (by jms courier) using *XAConnectionFactory* to the esb service.
In this case the connection pool uses XAConnectionFactory.createSession for creating the session. The pool has hashmaps which key is acknowledgement mode. JBossMQ's XAConnectionFactory.createSession always creates Session with SESSION_TRANSACTED acknowledgement mode. But the pool registers the session under customized acknowledgement mode into the maps (eg. AUTO_ACKNOWLEDGE). When session clean is called, the JmsConnectionPool tries to remove the session from the pool, but uses Session.getAcknowledgement to find out what type of session it is. This returns SESSION_TRANSACTED mode, but session was registered under eg. AUTO_ACKNOWLEDGE mode. The pool is not cleaned up correctly and overflows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 4 months
[JBoss JIRA] Created: (JBESB-2097) ServiceInvoker Exception details
by Burr Sutter (JIRA)
ServiceInvoker Exception details
--------------------------------
Key: JBESB-2097
URL: https://jira.jboss.org/jira/browse/JBESB-2097
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.4
Reporter: Burr Sutter
Current the ServiceInvoker.deliverSync() method might throw the following exceptions:
MessageDeliverException
RegistryException
FaultMessageException
requestMessage = MessageFactory.getInstance().getMessage();
requestMessage.getProperties().setProperty(Environment.EXCEPTION_ON_DELIVERY_FAILURE,"true");
ServiceInvoker invoker = new ServiceInvoker("MyCategory", "Service99");
replyMessage = invoker.deliverSync(requestMessage,2000);
A service name which does not exist results in a MessageDeliverException, with the following information exposed via a
System.err.println(mde);
11:25:16,179 ERROR [STDERR] org.jboss.soa.esb.listeners.message.MessageDeliverEx
ception: Failed to deliver message [header: [ ]] to Service [MyCategory:Servic
e99]. Check for errors.
It would have made more sense for it to be a RegistryException and the actual message doesn't indicate that there is a lookup problem.
Futhermore, a timeout results in the following MessageDeliverException:
11:45:06,278 ERROR [STDERR] org.jboss.soa.esb.listeners.message.MessageDeliverEx
ception: Failed to deliver message [header: [ To: InVMEpr [ PortReference < <wsa
:Address invm://52455354456173794553425365727669636531/false?false#10000/>, <wsa
:ReferenceProperties jbossesb:passByValue : false/>, <wsa:ReferenceProperties jb
ossesb:type : urn:jboss/esb/epr/type/invm/> > ] ReplyTo: InVMEpr [ PortReference
< <wsa:Address invm://thread-559/>, <wsa:ReferenceProperties jbossesb:passByVal
ue : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/in
vm/> > ] ]] to Service [MyCategory:Service1]. Told not to retry.
No indication that the problem is timeout and the "Told not to retry" is a bit terse.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 4 months