[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
16 years, 7 months
[JBoss JIRA] Created: (JBESB-2752) Message lost in case of exception in Message Composer
by Boris Belovic (JIRA)
Message lost in case of exception in Message Composer
-----------------------------------------------------
Key: JBESB-2752
URL: https://jira.jboss.org/jira/browse/JBESB-2752
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.4 CP2
Environment: Fedora 11, 4.3.0.GA_CP01_SOA
Reporter: Boris Belovic
I have written (very simple) custom composer class. It just receives a JMSObjectMessage and according to message contents it creates an ESB-aware message or throws an exception. The creation of ESB aware message works fine and the message is properly delivered to receiver. In the second case an exception is thrown and the original message should be redelivered, but this is not happening. Instead of redelivery, message is lost.
In case that an exception is thrown, the original message should be routed to deadletter queue. But when I try to obtain this message from the deadletter queue (either queue/DLQ or using a MessageStore instance), the queue is empty. It contains no messages and the message is lost.
I also tried to use jca-provider instead of jms-provider. This provider was also unable to deliver message to proper receiver. JCA provider tried several times to redeliver message, but after all the message ended up in DLQ queue (queue/DLQ).
--
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
16 years, 7 months
[JBoss JIRA] Created: (JBESB-2808) EBWS webservice is instantiated on every invocation
by Kevin Conner (JIRA)
EBWS webservice is instantiated on every invocation
---------------------------------------------------
Key: JBESB-2808
URL: https://jira.jboss.org/jira/browse/JBESB-2808
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Web Services
Affects Versions: 4.4 CP3
Reporter: Martin Vecera
Assignee: Kevin Conner
Priority: Critical
Fix For: 4.4 CP3
With every call of a Web Service published using EBWS, an instance of JAXWS provider (BaseWebService) is created, which requests new ServiceInvoker and a lookup into UDDI. Attached is a TrackingRegistryInterceptor which shows UDDI lookups and their duration.
This is a significant performance issue - after applying a partial workaround (see Workaround field) the performance almost doubled.
--
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
16 years, 7 months
[JBoss JIRA] Created: (JBESB-2809) EBWS creates SOAP message factory with every request
by Kevin Conner (JIRA)
EBWS creates SOAP message factory with every request
----------------------------------------------------
Key: JBESB-2809
URL: https://jira.jboss.org/jira/browse/JBESB-2809
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4 CP3
Environment: SOA-P 4.3.CP02 CR2
Reporter: Martin Vecera
Priority: Blocker
Fix For: 4.4 CP3
Every request to an ESB service published via EBWS requests can request several new SOAP message factories (at least one is created) - lookup javax.xml.soap.MessageFactory.newInstance() in org.jboss.internal.soa.esb.webservice.BaseWebService.
With a scenario, which causes ESB to create only one new message factory for a request, a 13% overhead is introduced.
--
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
16 years, 7 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
16 years, 7 months
[JBoss JIRA] Created: (JBESB-2797) HttpRouter fire java.lang.NullPointerException if the Status Code is 304 (Not Modified)
by Magesh Kumar B (JIRA)
HttpRouter fire java.lang.NullPointerException if the Status Code is 304 (Not Modified)
---------------------------------------------------------------------------------------
Key: JBESB-2797
URL: https://jira.jboss.org/jira/browse/JBESB-2797
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.6
Reporter: Magesh Kumar B
Assignee: Magesh Kumar B
Fix For: 4.7
When a GET is requested with If-Modified-Since in the header, the server responds with 304 - Not Modified with no Response Body[1] if the document requested is not modified since. We get the following error in such situations.
WARN [org.jboss.soa.esb.actions.routing.http.HttpRouter] Received status code '304' on HTTP org.apache.commons.httpclient.methods.GetMethod@5583aa request to 'http://server/url'.
ERROR [org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener] JBoss Remoting Gateway failed to synchronously deliver message to target service [Service:Category].
org.jboss.soa.esb.couriers.FaultMessageException: java.lang.IllegalArgumentException: null 'stream' arg passed in method call.
at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:580)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:493)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:343)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:204)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSyncWithoutDecomposing(UncomposedMessageDeliveryAdapter.java:107)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSync(UncomposedMessageDeliveryAdapter.java:86)
at org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener.invoke(JBossRemotingGatewayListener.java:345)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866)
at org.jboss.remoting.transport.coyote.CoyoteInvoker.service(CoyoteInvoker.java:310)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: null 'stream' arg passed in method call.
at org.jboss.internal.soa.esb.util.StreamUtils.readStream(StreamUtils.java:47)
at org.jboss.soa.esb.actions.routing.http.HttpRouter.process(HttpRouter.java:109)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:615)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:574)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:408)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
... 1 more
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
"10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields. "
--
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
16 years, 7 months
[JBoss JIRA] Created: (JBESB-2792) Bug in base-build.xml file - JBoss Remoting version control.
by Boris Belovic (JIRA)
Bug in base-build.xml file - JBoss Remoting version control.
------------------------------------------------------------
Key: JBESB-2792
URL: https://jira.jboss.org/jira/browse/JBESB-2792
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Examples
Affects Versions: 4.4
Environment: SOA 4.3.0 CP2 CR2
Reporter: Boris Belovic
Attachments: base-build.xml
I am testing quickstarts and I found a bug in quickstart/conf/base-build.xml file. The script expects JBoss Remoting 2.2.2SP version or higher, but the version 2.2.2SP seems to be hardcoded in the script. So even if I have higher version (2.2.3) the script fails. This bug prevents webservice_mtom, webservice_proxy quickstarts from being deployed correctly (deployment of these quickstarts fails).
Affected part of base-build.xml follows. It is a part of "assert-jbossremoting-version" target which starts on line 518 in base-build.xml.
<echo message="JBR Version String: '${jbr-version-string}'."/>
<condition property="is-valid-jbr-version">
<and>
<contains string="${jbr-version-string}" substring="2.2.2.SP" />
<not>
<contains string="${jbr-version-string}" substring="2.2.2.SP1 " />
</not>
</and>
</condition>
After I commented out the section above, both quickstarts were deployed correctly.
--
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
16 years, 7 months