September 2014 - esb-issues - Jboss List Archives

[JBoss JIRA] (JBESB-3974) Objectmapper not checking debug level

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3974?page=com.atlassian.jira.plugin... ] Tom Cunningham closed JBESB-3974. --------------------------------- > Objectmapper not checking debug level > ------------------------------------- > > Key: JBESB-3974 > URL: https://issues.jboss.org/browse/JBESB-3974 > Project: JBoss ESB > Issue Type: Task > Components: Message Store > Affects Versions: 4.12 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_12/product... > on line 283. object mapper does not check if debug level is enabled before calling log.debug. If high throughput or large messages can result in. > - lage young generation usage. > - High GC activity > - High CPU > Code should check if debug level enabled as specified by best practises for performance optimization -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3974) Objectmapper not checking debug level

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3974?page=com.atlassian.jira.plugin... ] Tom Cunningham resolved JBESB-3974. ----------------------------------- Resolution: Done Add test to see if debug is enabled before doing logger.debug and concatenating strings. > Objectmapper not checking debug level > ------------------------------------- > > Key: JBESB-3974 > URL: https://issues.jboss.org/browse/JBESB-3974 > Project: JBoss ESB > Issue Type: Task > Components: Message Store > Affects Versions: 4.12 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_12/product... > on line 283. object mapper does not check if debug level is enabled before calling log.debug. If high throughput or large messages can result in. > - lage young generation usage. > - High GC activity > - High CPU > Code should check if debug level enabled as specified by best practises for performance optimization -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3974) Objectmapper not checking debug level

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3974?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated JBESB-3974: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1107685 > Objectmapper not checking debug level > ------------------------------------- > > Key: JBESB-3974 > URL: https://issues.jboss.org/browse/JBESB-3974 > Project: JBoss ESB > Issue Type: Task > Components: Message Store > Affects Versions: 4.12 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_12/product... > on line 283. object mapper does not check if debug level is enabled before calling log.debug. If high throughput or large messages can result in. > - lage young generation usage. > - High GC activity > - High CPU > Code should check if debug level enabled as specified by best practises for performance optimization -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3974) Objectmapper not checking debug level

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3974: ------------------------------------- Summary: Objectmapper not checking debug level Key: JBESB-3974 URL: https://issues.jboss.org/browse/JBESB-3974 Project: JBoss ESB Issue Type: Task Components: Message Store Affects Versions: 4.12 Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.13 http://anonsvn.jboss.org/repos/labs/labs/jbossesb/tags/JBESB_4_12/product... on line 283. object mapper does not check if debug level is enabled before calling log.debug. If high throughput or large messages can result in. - lage young generation usage. - High GC activity - High CPU Code should check if debug level enabled as specified by best practises for performance optimization -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3861) Update commons-codec libraries

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3861?page=com.atlassian.jira.plugin... ] Tom Cunningham closed JBESB-3861. --------------------------------- > Update commons-codec libraries > ------------------------------ > > Key: JBESB-3861 > URL: https://issues.jboss.org/browse/JBESB-3861 > Project: JBoss ESB > Issue Type: Task > Components: Rosetta > Affects Versions: 4.11 > Reporter: Martin Weiler > Assignee: Tom Cunningham > > We're getting this exception when we're trying to send a large (>200Mb) message to a subsequent action. Full stacktrace follows: > ERROR [org.jboss.soa.esb.client.ServiceInvoker] (pool-58-thread-1) Unexpected throwable during attempted message delivery using Courier for EPR [JMSEpr ... ]]. > java.lang.NegativeArraySizeException > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:258) > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:178) > at org.jboss.internal.soa.esb.util.Encoding.encodeBytes(Encoding.java:43) > at org.jboss.internal.soa.esb.util.Encoding.encodeObject(Encoding.java:62) > at org.jboss.internal.soa.esb.message.format.xml.marshal.SerializedMarshalUnmarshalPlugin.marshal(SerializedMarshalUnmarshalPlugin.java:83) > at org.jboss.internal.soa.esb.message.format.xml.marshal.MarshalUnmarshalManager.marshal(MarshalUnmarshalManager.java:145) > 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) > at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:224) > at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:187) > at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:189) > at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:702) > at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:604) > at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:392) > at org.jboss.soa.esb.client.ServiceInvoker.deliverAsync(ServiceInvoker.java:265) > An upgrade of the commons-codec libraries from the currently bundled version 1.3 includes a fix for CODEC-61 [1]. This would allow to Base64 encode input data up to 2GB, instead of the ~250MB limitation in common codecs version 1.3. > [1] https://issues.apache.org/jira/browse/CODEC-61 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3861) Update commons-codec libraries

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3861?page=com.atlassian.jira.plugin... ] Tom Cunningham resolved JBESB-3861. ----------------------------------- Assignee: Tom Cunningham Resolution: Done Upgraded to commons codec 1.9. Tested that >250MB messages do not receive the NegativeArraySizeException. Tested a good number of quickstarts to make sure that there's no regressions. Commons codec 1.9 only supports >= JDK 1.6, but after looking at the SOA-P 5.3.1 requirements, that looks okay. > Update commons-codec libraries > ------------------------------ > > Key: JBESB-3861 > URL: https://issues.jboss.org/browse/JBESB-3861 > Project: JBoss ESB > Issue Type: Task > Components: Rosetta > Affects Versions: 4.11 > Reporter: Martin Weiler > Assignee: Tom Cunningham > > We're getting this exception when we're trying to send a large (>200Mb) message to a subsequent action. Full stacktrace follows: > ERROR [org.jboss.soa.esb.client.ServiceInvoker] (pool-58-thread-1) Unexpected throwable during attempted message delivery using Courier for EPR [JMSEpr ... ]]. > java.lang.NegativeArraySizeException > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:258) > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:178) > at org.jboss.internal.soa.esb.util.Encoding.encodeBytes(Encoding.java:43) > at org.jboss.internal.soa.esb.util.Encoding.encodeObject(Encoding.java:62) > at org.jboss.internal.soa.esb.message.format.xml.marshal.SerializedMarshalUnmarshalPlugin.marshal(SerializedMarshalUnmarshalPlugin.java:83) > at org.jboss.internal.soa.esb.message.format.xml.marshal.MarshalUnmarshalManager.marshal(MarshalUnmarshalManager.java:145) > 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) > at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:224) > at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:187) > at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:189) > at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:702) > at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:604) > at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:392) > at org.jboss.soa.esb.client.ServiceInvoker.deliverAsync(ServiceInvoker.java:265) > An upgrade of the commons-codec libraries from the currently bundled version 1.3 includes a fix for CODEC-61 [1]. This would allow to Base64 encode input data up to 2GB, instead of the ~250MB limitation in common codecs version 1.3. > [1] https://issues.apache.org/jira/browse/CODEC-61 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3973) Configure default timeout for WSDL retrieval in SOAPProxy

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3973?page=com.atlassian.jira.plugin... ] Tom Cunningham closed JBESB-3973. --------------------------------- > Configure default timeout for WSDL retrieval in SOAPProxy > --------------------------------------------------------- > > Key: JBESB-3973 > URL: https://issues.jboss.org/browse/JBESB-3973 > Project: JBoss ESB > Issue Type: Bug > Components: Web Services > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > A very basic install stops responding to http requests - just hangs. It is listening to port 8080 on an external IP, but "curl http://<ip>:8080 just hangs. The log file does not contain errors or even attempts to connect. No services responds either. > The server is a clean install of SOA-P 5.3.1 with JDK 1.7 - it has two services deployed but no further customizations from the standard install. > Suspect bad JDK or bad host configuration. > IP is secondary IP of the server which has two IPs for the same NIC. It does not matter if we use -b x.x.x.x or -b alias - the situation is the same after startup. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3973) Configure default timeout for WSDL retrieval in SOAPProxy

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3973?page=com.atlassian.jira.plugin... ] Tom Cunningham resolved JBESB-3973. ----------------------------------- Resolution: Done > Configure default timeout for WSDL retrieval in SOAPProxy > --------------------------------------------------------- > > Key: JBESB-3973 > URL: https://issues.jboss.org/browse/JBESB-3973 > Project: JBoss ESB > Issue Type: Bug > Components: Web Services > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > A very basic install stops responding to http requests - just hangs. It is listening to port 8080 on an external IP, but "curl http://<ip>:8080 just hangs. The log file does not contain errors or even attempts to connect. No services responds either. > The server is a clean install of SOA-P 5.3.1 with JDK 1.7 - it has two services deployed but no further customizations from the standard install. > Suspect bad JDK or bad host configuration. > IP is secondary IP of the server which has two IPs for the same NIC. It does not matter if we use -b x.x.x.x or -b alias - the situation is the same after startup. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3973) Configure default timeout for WSDL retrieval in SOAPProxy

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3973?page=com.atlassian.jira.plugin... ] Tom Cunningham commented on JBESB-3973: --------------------------------------- Added socket and connection timeout properties which are set on the httpclient. Example : <action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy"> <property name="wsdl" value="http://www.foobar.com/mywsdl?wsdl"/> <property name="http.connection.timeout" value="10"/> <property name="http.socket.timeout" value="10"/> </action> bananastand:product tcunning$ svn commit services/ Sending services/soap/src/main/java/org/jboss/soa/esb/actions/soap/RemoteWsdlLoader.java Transmitting file data . Committed revision 38448. > Configure default timeout for WSDL retrieval in SOAPProxy > --------------------------------------------------------- > > Key: JBESB-3973 > URL: https://issues.jboss.org/browse/JBESB-3973 > Project: JBoss ESB > Issue Type: Bug > Components: Web Services > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > A very basic install stops responding to http requests - just hangs. It is listening to port 8080 on an external IP, but "curl http://<ip>:8080 just hangs. The log file does not contain errors or even attempts to connect. No services responds either. > The server is a clean install of SOA-P 5.3.1 with JDK 1.7 - it has two services deployed but no further customizations from the standard install. > Suspect bad JDK or bad host configuration. > IP is secondary IP of the server which has two IPs for the same NIC. It does not matter if we use -b x.x.x.x or -b alias - the situation is the same after startup. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3973) Configure default timeout for WSDL retrieval in SOAPProxy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3973?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated JBESB-3973: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1141340 > Configure default timeout for WSDL retrieval in SOAPProxy > --------------------------------------------------------- > > Key: JBESB-3973 > URL: https://issues.jboss.org/browse/JBESB-3973 > Project: JBoss ESB > Issue Type: Bug > Components: Web Services > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > A very basic install stops responding to http requests - just hangs. It is listening to port 8080 on an external IP, but "curl http://<ip>:8080 just hangs. The log file does not contain errors or even attempts to connect. No services responds either. > The server is a clean install of SOA-P 5.3.1 with JDK 1.7 - it has two services deployed but no further customizations from the standard install. > Suspect bad JDK or bad host configuration. > IP is secondary IP of the server which has two IPs for the same NIC. It does not matter if we use -b x.x.x.x or -b alias - the situation is the same after startup. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues September 2014