[JBoss JIRA] Created: (JBESB-3693) Remove connections properties and tests from jbossesb-properties.xml
by Tom Cunningham (JIRA)
Remove connections properties and tests from jbossesb-properties.xml
--------------------------------------------------------------------
Key: JBESB-3693
URL: https://issues.jboss.org/browse/JBESB-3693
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 4.10
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.10 CP1
The connections part of the jbossesb-properties.xml is obsoleted (found nowhere in code). Remove it from jbossesb-properties.xml files and tests, as well as the "connection" entries in ModulePropertyManager
<properties name="connection">
<property name="min-pool-size" value="5"/>
<property name="max-pool-size" value="10"/>
<property name="blocking-timeout-millis" value="5000"/>
<property name="abandoned-connection-timeout" value="10000"/>
<property name="abandoned-connection-time-interval" value="30000"/>
</properties>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 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, 7 months
[JBoss JIRA] (JBESB-3745) JON event logging / ESB MVEL action
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3745:
-------------------------------------
Summary: JON event logging / ESB MVEL action
Key: JBESB-3745
URL: https://issues.jboss.org/browse/JBESB-3745
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Management
Affects Versions: 4.11
Reporter: Tom Cunningham
Fix For: 4.11
Investigate the creation of a custom log which will then be fed into JON through the event stream. Try to see what sort of filtering and aggregation that JON provides that will allow us to provide a nicer view than just the log entry (i.e. X number of events within the past 3 hours, whether we can trigger notifications off of groups of events, etc).
Possibly add an additional Quickstart around this area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBESB-3708) XsltAction cannot handle org.w3c.dom.Document
by David Tucker (Created) (JIRA)
XsltAction cannot handle org.w3c.dom.Document
---------------------------------------------
Key: JBESB-3708
URL: https://issues.jboss.org/browse/JBESB-3708
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.10
Reporter: David Tucker
Currently the XsltAction can handle the following objects:
String, byte[], Reader, InputStream, File, or Source
The output from the XsltAction, when choosing DOM, is an object that implements the interface org.w3c.dom.Document. The action can't accept the document it created to run another transformation on it. While this scenario is remote at best, it is not unlikely that we would want to run a transformation on a Document. I was able to create a custom action that would allow me to put a Document into a DOMSource object. This requires extra work anytime I want to use a Document in an XSLT and the Document interface should be an accepted way of sending a document to be transformed. The following code was all it took in my custom action:
DOMSource domSource = new DOMSource();
domSource.setNode(doc.getFirstChild()); //doc is an object implementing org.w3c.dom.Document
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 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, 7 months
[JBoss JIRA] (JBESB-3739) Detect CLIENT_ACKNOWLEDGE mode using jms-provider on non-gateway queues
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3739:
-------------------------------------
Summary: Detect CLIENT_ACKNOWLEDGE mode using jms-provider on non-gateway queues
Key: JBESB-3739
URL: https://issues.jboss.org/browse/JBESB-3739
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Message Store
Affects Versions: 4.11
Reporter: Tom Cunningham
Fix For: 4.11
Description of problem:
CLIENT_ACKNOWLEDGE mode is not valid for a non-gateway listener using
jms-provider.
If using the jms-provider then the message will be retrieved by the
JmsCourier and converted into an ESB message, after which there is no
longer a reference to the underlying JMS message. The JmsCourier should
be detecting this and raising an exception.
Version-Release number of selected component (if applicable):
JBoss ESB 4.10
How reproducible:
Consistently
Steps to Reproduce:
1. Modfiy jboss-esb.xml of helloworld quickstart:
<jms-provider name="JBossMQ"
connection-factory="XAConnectionFactory">
<jms-bus busid="quickstartGwChannel">
<jms-message-filter
dest-type="QUEUE"
dest-name="queue/quickstart_helloworld_Request_gw"
transacted="false"
acknowledge-mode="CLIENT_ACKNOWLEDGE"
/>
</jms-bus>
<jms-bus busid="quickstartEsbChannel">
<jms-message-filter
dest-type="QUEUE"
dest-name="queue/quickstart_helloworld_Request_esb"
transacted="false"
acknowledge-mode="CLIENT_ACKNOWLEDGE"
/>
</jms-bus>
</jms-provider>
2. Invoke ant runtest
Actual results:
Message remains in the non-gateway queue after ESB service has been invoked.
Expected results:
An exception should be raised indicating that CLIENT_ACKNOWLEDGE mode is not
supported on non-gateway queues using jms-listener.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBESB-3721) NullPointerException deploying a scheduled-listener with invalid scheduleidref attribute
by Martin Weiler (Created) (JIRA)
NullPointerException deploying a scheduled-listener with invalid scheduleidref attribute
----------------------------------------------------------------------------------------
Key: JBESB-3721
URL: https://issues.jboss.org/browse/JBESB-3721
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment
Affects Versions: 4.10
Reporter: Martin Weiler
Deploying a service with a schedule-listener using an incorrect value for the scheduleidref attribute results in a NullPointerException:
{noformat}
ERROR [AbstractKernelController] Error installing to Start: name=jboss.esb.vfszip:/data/jboss/work/jboss-soa-p-5.2.0.GA/jboss-as/server/test/deploy/Quickstart_scheduled_services.esb/ state=Create
java.lang.RuntimeException: java.lang.NullPointerException
at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:185)
...
Caused by: java.lang.NullPointerException
at org.jboss.soa.esb.listeners.config.mappers.ScheduleMapper.map(ScheduleMapper.java:61)
at org.jboss.soa.esb.listeners.config.mappers.ESBAwareGenerator.addESBAwareConfig(ESBAwareGenerator.java:216)
at org.jboss.soa.esb.listeners.config.mappers.ESBAwareGenerator.generate(ESBAwareGenerator.java:102)
at org.jboss.soa.esb.listeners.config.mappers.XMLBeansModel.generateESBAwareConfig(XMLBeansModel.java:441)
{noformat}
The existence of the referenced schedule-provider should be verified, and if it does not exist, a meaningful exception should be thrown instead of the NullPointerException.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 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, 7 months