[JBoss JIRA] Created: (JBESB-3597) DLQ handling on JCA side causes duplicate redelivery to DLQ
by Toshiya Kobayashi (JIRA)
DLQ handling on JCA side causes duplicate redelivery to DLQ
-----------------------------------------------------------
Key: JBESB-3597
URL: https://issues.jboss.org/browse/JBESB-3597
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Adapters, Examples
Affects Versions: 4.9 CP1
Reporter: Toshiya Kobayashi
JCA DLQ handling interferes with JBM DLQ handling and may end up with unexpected results. You can find discussions in JBAS-7465 and JBPAPP-3352.
In ESB, you can reproduce the issue with jms_transacted quickstart.
====================
- Edit jboss-esb.xml to set dLQMaxResent=3
<property name="dLQMaxResent" value="3"/>
- ant deplpy
- ant runtest
The message will be sent to DLQ.
- Check jboss.messaging.destination:name=DLQ,service=Queue via jmx-console
You will see MessageCount=1
- Check jboss.esb.quickstart.destination:name=quickstart_jms_transacted_Request_esb,service=Queue via jmx-console
You will see MessageCount=1, DeliveringCount=1 though the message has been sent to DLQ.
- ant deploy
Redeploying the queue causes re-delivering the message to DLQ
- Check jboss.messaging.destination:name=DLQ,service=Queue via jmx-console
You will see MessageCount=2 (duplicate).
=====================
Looking at JBAS-7465 and JBPAPP-3352, there is less chance to resolve the root issue from AS/JBM side. I filed this JIRA for something we can address from ESB side.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBESB-3010) SyncServiceInvoker: Failed to send fault message in case of exception.
by Boris Belovic (JIRA)
SyncServiceInvoker: Failed to send fault message in case of exception.
----------------------------------------------------------------------
Key: JBESB-3010
URL: https://jira.jboss.org/jira/browse/JBESB-3010
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.7
Reporter: Boris Belovic
I made simple service with SyncServiceInvoker action. SyncServiceInvoker is configured to fail when proxied service throws an exception. Fault message is not sent to the sender and I got this exception.
2009-11-30 08:54:55,076 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] (pool-41-thread-1) Unexpected exception caught while processing the action pipeline: header: [ To: JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/serviceA_esb/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] ReplyTo: JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : jbossESBresponseUUID='616488c6-8ffc-4539-9237-dcaf8cebec81'/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] MessageID: 8d6450a3-f5f4-4c97-8656-a4c6b5836bfb RelatesTo: jms:correlationID#8d6450a3-f5f4-4c97-8656-a4c6b5836bfb ]
org.jboss.soa.esb.actions.ActionProcessingException: Error delivering message to service 'Services:ServiceB'
at org.jboss.soa.esb.actions.SyncServiceInvoker.process(SyncServiceInvoker.java:85)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:634)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
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)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.soa.esb.couriers.FaultMessageException: org.jboss.soa.esb.actions.ActionProcessingException: This is an ActionProcessingException.
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:675)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:569)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:359)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
at org.jboss.soa.esb.actions.SyncServiceInvoker.process(SyncServiceInvoker.java:77)
... 7 more
Caused by: org.jboss.soa.esb.actions.ActionProcessingException: This is an ActionProcessingException.
at org.jboss.soa.esb.samples.quickstart.syncserviceinvoker.ExceptionAction.process(ExceptionAction.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.processMethods(ActionProcessorMethodInfo.java:102)
at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcessor.process(OverriddenActionLifecycleProcessor.java:74)
... 7 more
2009-11-30 08:54:55,076 DEBUG [org.jboss.soa.esb.filter.FilterManager] (pool-41-thread-1) FilterManager calling org.jboss.internal.soa.esb.message.filter.MetaDataFilter(a)594482c8.onOutput
2009-11-30 08:54:55,076 DEBUG [org.jboss.soa.esb.filter.FilterManager] (pool-41-thread-1) FilterManager calling org.jboss.internal.soa.esb.message.filter.GatewayFilter(a)20e64641.onOutput
2009-11-30 08:54:55,099 ERROR [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] (pool-41-thread-1) Failed to send fault to address JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : jbossESBresponseUUID='616488c6-8ffc-4539-9237-dcaf8cebec81'/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] for message header: [ To: JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : jbossESBresponseUUID='616488c6-8ffc-4539-9237-dcaf8cebec81'/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] From: JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/serviceA_esb/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] RelatesTo: 8d6450a3-f5f4-4c97-8656-a4c6b5836bfb ]
org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException: Failed to serialize ESB Message.
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:224)
at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:181)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:189)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.messageTo(ActionProcessingPipeline.java:861)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.faultTo(ActionProcessingPipeline.java:811)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:666)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
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)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Util.serialize caught XMLStreamException:
at org.jboss.soa.esb.util.Util.serialize(Util.java:198)
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:218)
... 11 more
Caused by: javax.xml.stream.XMLStreamException
at org.jboss.internal.soa.esb.message.format.xml.marshal.MarshalUnmarshalManager.marshal(MarshalUnmarshalManager.java:149)
at org.jboss.internal.soa.esb.message.format.xml.BodyImpl.writeChildContent(BodyImpl.java:146)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.internal.soa.esb.util.stax.StreamHelper.writeElement(StreamHelper.java:125)
at org.jboss.internal.soa.esb.message.format.xml.MessageImpl.writeChildContent(MessageImpl.java:236)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.soa.esb.util.Util.serialize(Util.java:188)
... 12 more
--
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
12 years, 4 months
[JBoss JIRA] Created: (JBESB-3583) MessageAwareListener Thread Pool does not clean up idle threads
by Peter Nordquist (JIRA)
MessageAwareListener Thread Pool does not clean up idle threads
---------------------------------------------------------------
Key: JBESB-3583
URL: https://issues.jboss.org/browse/JBESB-3583
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.9, 4.8
Environment: JBoss 5.1.0.GA with ESB 4.8 running on Win 7 64-bit, Mac OS X, and RHEL 5.5 all running MySQL 5.1.5x
Java 1.6.0_20 and Java 1.6.0_24
Reporter: Peter Nordquist
In the MessageAwareListener at http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/s... on line 232 a fixed thread pool is allocated. This causes the possibility of having at most maxThreads around for the life of the App server even if the service is not being used. Behind the scenes the Executors.newFixedThreadPool(_maxThreads) creates a java.util.concurrent.ThreadPoolExecutor with a core pool size of maxThreads and a max pool size of maxThreads and 0L for the keep alive time and giving it a new LinkedBlockingQueue<Runnable>() for the queue. This Executor will not precreate the threads but as calls happen it will allocate threads as needed and keep them around forever since the core pool size is the same as the max pool size. If there are a large number of services defined with high values for maxThreads a 'java.lang.OutOfMemoryError: unable to create new native thread' exception will occur. I suggest that you fix this by actually instantiating a java.util.concurrent.ThreadPoolExecutor with a core pool size of something other than maxThreads (possibly 0 since it would then destroy all threads when they are not needed) a max pool size of the passed in maxThreads and a keep alive time of your choice. We are currently using 4.8 but are evaluating 4.9 and see the same problem in that version.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (JBESB-3128) http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service
by Len DiMaggio (JIRA)
http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service
------------------------------------------------------------------------------------------------------------------
Key: JBESB-3128
URL: https://jira.jboss.org/jira/browse/JBESB-3128
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.7
Environment: 4.7 GA
Reporter: Len DiMaggio
I'm seeing a very odd problem with the ESB's http_gateway synchronousTimeout property.
Briefly - the timer operates 100% slower than it should - but only the first time the timer is invoked for deployed .esb archive. This is reproducible at will with ESB 4.7 and SOA-P 5.0 ER7.
After experimenting with this - the delay seems to be on a per-service basis - in other words, the first time a service that hits synchronousTimeout, the timeout operates twice as slow as it should. Starting with the second time that a service encounters a synchronousTimeout, the timeout operates as expected.
I'm seeing this with the default synchronousTimeout value, and if the value is defined in the service definition in jboss-esb.xml
========================================
A modified version of the http_gateway quickstart is attached to demonstrate the problem. The modifications are:
* A new action class (my40secAction) is added - this class is identical to myAction, except that it introduces a 40 seconde delay.
* A modified jboss-esb.xml file - the Sales:List service is modified to have a 10 second synchronousTimeout, and the action invokes the My40secAction class - and a second service (SlowSales) is added - this service is a clone of Sales:List:
<service category="Sales" name="List" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
authenticate because the "sales" bus has basic auth configured (above)... -->
<http-gateway name="sales" busidref="secureFriends" urlPattern="sales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/>
</actions>
</service>
<service category="SlowSales" name="SlowList" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
authenticate because the "sales" bus has basic auth configured (above)... -->
<http-gateway name="slowsales" busidref="secureFriends" urlPattern="slowsales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/>
</actions>
</service>
========================================
Here's an example of the behavior I'm seeing:
Test run #1 - approx 20 sec - unexpected as the test is configured for 10 sec timeout
[ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date
Fri Jan 15 15:52:47 EST 2010
<html><head><title>JBoss Web/2.1.3 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: Failed to deliver message.
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>root cause</b> <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List].
org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427)
org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:07 EST 2010
Then - immediately follows test run #2 - approx 10 seconds - this is what I would have expected
[ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date
Fri Jan 15 15:53:14 EST 2010
<html><head><title>JBoss Web/2.1.3 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: Failed to deliver message.
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>root cause</b> <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List].
org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427)
org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:25 EST 2010
--
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
12 years, 5 months
[JBoss JIRA] Created: (JBESB-3587) Enabling xslt parameters support in XsltAction
by Eduardo de Vera Toquero (JIRA)
Enabling xslt parameters support in XsltAction
----------------------------------------------
Key: JBESB-3587
URL: https://issues.jboss.org/browse/JBESB-3587
Project: JBoss ESB
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Transformation Service
Affects Versions: 4.9
Environment: Linux
Reporter: Eduardo de Vera Toquero
Priority: Minor
Enhancement of xslt parameters in order to be able to pass values to xslt parameters on the xslt action. Ideally, using prefixes, one could chose whether to pass a value located at the configuration file (ConfigTree) or from the ESB Message. Values need to be stringed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBESB-3561) Registry Error When JBOSS bind to 0.0.0.0
by Anurag Debnath (JIRA)
Registry Error When JBOSS bind to 0.0.0.0
-----------------------------------------
Key: JBESB-3561
URL: https://issues.jboss.org/browse/JBESB-3561
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss Enterprise SOA Platform 5.0.1
Reporter: Anurag Debnath
When the server hosting ESB is started with flag -b 0.0.0.0, the UDDI
registry puts services under this address and are thus unreachable by
remote ServiceInvokers.
Tested by deploying 'HelloWorld' quickstart and examining UDDI through
the UDDI console.
* Start server with no flags. Examing UDDI registry will show service
is bound to '127.0.0.1'
* Start server with -b 123.123.123.123. UDDI registry will show service
bound to '123.123.123.123'
* Start server with -b 0.0.0.0 UDDI registry will show service bound to
'0.0.0.0' (unreachable remotely)
* Start server with -b 0.0.0.0 -Djboss.esb.bind.address=123.123.123.123
UDDI registry will show service bound to '0.0.0.0'
* Start server with -b 0.0.0.0 and JAVA_OPTS including
"jboss.esb.bind.address=123.123.123.123" UDDI registry will show service
bound to '0.0.0.0'
Proposed fix is a system property read by
org.jboss.soa.esb.helpers.NamingContextPool that specifies the desired
octet to plug into java.naming.provider.url.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months