[ESBJAVA-4861] Provide an option to enable statistics globally for ESB 4.9.0 or previous version statistics implementation Created: 23/Aug/16  Updated: 29/Aug/16  Resolved: 29/Aug/16

Status: Resolved
Project: WSO2 ESB
Component/s: None
Affects Version/s: 4.9.0
Fix Version/s: 5.0.0

Type: Patch Priority: High
Reporter: Isuru Udana Loku Narangoda Assignee: Chanaka Fernando
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Estimated Complexity: Moderate
Test cases added: Yes

 Description   

It is nice to have a way to enable statistics globally to quickly turn on and turn off statistics of the server globally without touching the individual artifacts



 Comments   
Comment by Rajith Vitharana [ 29/Aug/16 ]

This is already available in latest ESB 5.0.0 with fix commits [1] and [2]

[1] - https://github.com/wso2/wso2-synapse/commit/2e857f9d3e3234e1c55eb08107fdc2101ce5d68d
[2] - https://github.com/wso2/wso2-synapse/commit/9b8491e90cc8f54e64412d1375274b7252ef5866





[ESBJAVA-4850] NumberFormatException if Content-length is greater than Integer.MAX value Created: 17/Aug/16  Updated: 26/Aug/16  Resolved: 26/Aug/16

Status: Resolved
Project: WSO2 ESB
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: High
Reporter: Isuru Udana Loku Narangoda Assignee: Janaka Ranabahu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned as APIMANAGER-5349 NumberFormatException if Content-leng... Resolved
Severity: Major
Estimated Complexity: Moderate
Test cases added: Yes

 Description   

If the content-length is greater than Integer.MAX value we are getting a number format exception.

[2016-08-05 15:44:13,296] ERROR - SourceHandler Unexpected error: For input string: "3630138999"
java.lang.NumberFormatException: For input string: "3630038999"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:495)
at java.lang.Integer.parseInt(Integer.java:527)
at org.apache.synapse.transport.passthru.SourceResponse.start(SourceResponse.java:133)
at org.apache.synapse.transport.passthru.SourceHandler.responseReady(SourceHandler.java:193)
at org.apache.http.impl.nio.DefaultNHttpServerConnection.produceOutput(DefaultNHttpServerConnection.java:247)
at org.apache.synapse.transport.http.conn.LoggingNHttpServerConnection.produceOutput(LoggingNHttpServerConnection.java:114)
at org.apache.synapse.transport.passthru.ServerIODispatch.onOutputReady(ServerIODispatch.java:87)
at org.apache.synapse.transport.passthru.ServerIODispatch.onOutputReady(ServerIODispatch.java:39)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.outputReady(AbstractIODispatch.java:148)
at org.apache.http.impl.nio.reactor.BaseIOReactor.writable(BaseIOReactor.java:181)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:346)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:320)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:280)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:106)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:604)

In our code, we have assumed that content-legth cannot exceed Integer.MAX. But specs says we can have any value to that header.

"Any Content-Length greater than or equal to zero is a valid value"



 Comments   
Comment by Janaka Ranabahu [ 26/Aug/16 ]

Fixed with 943fe1fe0abd95c553da8904d7a529873c2e4c5a





[ESBJAVA-4872] Axis2 SMS transport doesn't invalidate the existing session after an error and the fault Sequence never got hit. Created: 25/Aug/16  Updated: 25/Aug/16  Resolved: 25/Aug/16

Status: Resolved
Project: WSO2 ESB
Component/s: Transport
Affects Version/s: None
Fix Version/s: 5.1.0

Type: Improvement Priority: Normal
Reporter: Kesavan Yogarajah Assignee: Chanaka Fernando
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: Major
Estimated Complexity: Moderate
Attachment License: I agree to grant a license to WSO2 for this work for inclusion in WSO2 works as per the WSO2 Contributor License Agreement and the Apache License 2.0
Test cases added: Yes

 Description   

The axis2 SMS transport doesn't invalidate the existing session after an error. It keeps trying with the same session so that the connection created during server startup is never get refreshed and the fault Sequence never got hit.



 Comments   
Comment by Kesavan Yogarajah [ 25/Aug/16 ]

Fixed in https://github.com/wso2/wso2-axis2-transports/pull/104

Comment by Balasubramaniyam Senduran [ 25/Aug/16 ]

PR is merged in https://github.com/wso2/wso2-axis2-transports/commit/45dfbada7045d3fe5b5bba983819843d77dcccbf





[ESBJAVA-4864] Fault sequence not triggered on error when building the message in jms inbound endpoint Created: 23/Aug/16  Updated: 25/Aug/16  Resolved: 25/Aug/16

Status: Resolved
Project: WSO2 ESB
Component/s: None
Affects Version/s: 4.9.0
Fix Version/s: 5.1.0

Type: Bug Priority: Normal
Reporter: Nuwan Wimalasekara Assignee: Nuwan Wimalasekara
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: Major
Estimated Complexity: Moderate
Test cases added: Yes

 Description   

JMS inbound endpoint does not trigger the fault sequence when error happens on message building.



 Comments   
Comment by Nuwan Wimalasekara [ 25/Aug/16 ]

Fixed in https://github.com/wso2/carbon-mediation/pull/743
Test Added in https://github.com/wso2/product-esb/pull/590





[ESBJAVA-4863] JMS Transaction roll back not working for topic message in inbound endpoint Created: 23/Aug/16  Updated: 25/Aug/16  Resolved: 25/Aug/16

Status: Resolved
Project: WSO2 ESB
Component/s: None
Affects Version/s: 4.9.0
Fix Version/s: 5.1.0

Type: Bug Priority: Normal
Reporter: Nuwan Wimalasekara Assignee: Nuwan Wimalasekara
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Severity: Major
Estimated Complexity: Moderate
Test cases added: Yes

 Description   

if the message is roll back after failure, inbound endpoint does not roll back the message properly. ESB should get the message again from broker and try to process after roll back.



 Comments   
Comment by Nuwan Wimalasekara [ 25/Aug/16 ]

Fixed in https://github.com/wso2/carbon-mediation/pull/743
Test Added in https://github.com/wso2/product-esb/pull/590





[ESBJAVA-4293] Exception is thrown when you create a topic without configuring topic name in jndi.properties in Inbound Endpoints Created: 29/Oct/15  Updated: 25/Aug/16  Resolved: 25/Aug/16

Status: Resolved
Project: WSO2 ESB
Component/s: Inbound Endpoints
Affects Version/s: 4.9.0
Fix Version/s: 5.1.0

Type: Bug Priority: High
Reporter: Dilini Gunatilake Assignee: Nuwan Wimalasekara
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Ubuntu 14.04
JDK: 1.7.0_79
Database : H2
Browser : Firefox 40.0
Setup : Standalone


Attachments: PNG File Screenshot from 2015-10-29 17-08-13.png    
Severity: Major
Estimated Complexity: Moderate
Test cases added: No

 Description   

This issue is observed when you try to create a JMS topic subscriber with Inbound Endpoints integrated with MB 3.0.0 Beta.

Steps to recreate
------------------------------------------------------------------------------------------------------------
1. Create an inbound endpoint for the a topic with configurations are shown in the screen shot.
2. Configure the jndi.properties file as follows.

connectionfactory.QueueConnectionFactory = amqp://admin:admin@carbon/carbon?brokerlist='tcp://localhost:5673'

connectionfactory.TopicConnectionFactory = amqp://admin:admin@carbon/carbon?brokerlist='tcp://localhost:5673'

# register some queues in JNDI using the form
# queue.[jndiName] = [physicalName]
queue.MyQueue = MyQueue

# register some topics in JNDI using the form
# topic.[jndiName] = [physicalName]
topic.MyTopic222 = MyTopic222

Note: The destination "MyTopic" is not configured in the jndi.properties file

Issue
--------------------------------------------------------------------------------------------------------------
Exception is thrown as follows and a topic will not be created with the given name.

[2015-10-29 16:58:29,339] ERROR - JMSConnectionFactory JMS Exception while creating consumer. Object org.wso2.andes.client.AMQSession_0_8@4b317eca has been closed
[2015-10-29 16:58:29,339] ERROR - JMSPollingConsumer Error while receiving JMS message. null
java.lang.NullPointerException
	at org.wso2.carbon.inbound.endpoint.protocol.jms.JMSPollingConsumer.receiveMessage(JMSPollingConsumer.java:247)
	at org.wso2.carbon.inbound.endpoint.protocol.jms.JMSPollingConsumer.poll(JMSPollingConsumer.java:135)
	at org.wso2.carbon.inbound.endpoint.protocol.jms.JMSPollingConsumer.execute(JMSPollingConsumer.java:98)
	at org.wso2.carbon.inbound.endpoint.protocol.jms.JMSTask.taskExecute(JMSTask.java:45)
	at org.wso2.carbon.inbound.endpoint.common.InboundTask.execute(InboundTask.java:44)
	at org.wso2.carbon.mediation.ntask.NTaskAdapter.execute(NTaskAdapter.java:90)
	at org.wso2.carbon.ntask.core.impl.TaskQuartzJobAdapter.execute(TaskQuartzJobAdapter.java:67)
	at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)

But, when you try to create a queue, you can give any name regardless of the queue name configured in the jndi.properties file and a queue will be created. So, there is a conflict in the behavior for queues and topics.



 Comments   
Comment by Nuwan Wimalasekara [ 25/Aug/16 ]

Fixed in https://github.com/wso2/carbon-mediation/pull/743





[ESBJAVA-3573] Payload Factory Mediator throws XML Parser Exception If args value begins with html tag Created: 19/Feb/15  Updated: 23/Aug/16  Resolved: 23/Aug/16

Status: Resolved
Project: WSO2 ESB
Component/s: None
Affects Version/s: 4.8.1, 4.9.0
Fix Version/s: None

Type: Patch Priority: High
Reporter: isuru ranawaka Assignee: Rajith Vitharana
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Estimated Complexity: Moderate
Test cases added: Yes

 Comments   
Comment by isuru ranawaka [ 19/Feb/15 ]

https://github.com/wso2/wso2-synapse/pull/89

Comment by Chanaka Fernando [ 02/Oct/15 ]

This issue has been reopened due to a performance regression issue occurred due to this fix. This PR has been reverted.

Comment by Rajith Vitharana [ 23/Aug/16 ]

Fixed with below commits

wso2-synapse (public master)
commit - 6348cfc9cef272e2c873a6074a42c68979ea0037
pull - https://github.com/wso2/wso2-synapse/pull/648

carbon-mediation (public master)
commit - 34628ab8782709db74e309f2696fcff673e3b10b, 544a97271c7ad0f50d5633b3d32c8d8177ee33ff
pull - https://github.com/wso2/carbon-mediation/pull/740, https://github.com/wso2/carbon-mediation/pull/741

Fix description is as mentioned below

This fix resolves the issue where payload factory throws and error when argument value begins with html tag.

This happens because ESB is trying to identify whether the argument value is a XML value or not(Earlier logic was to check for the begin element, which passes when there is "<" in the begining). Reason for this identification is to convert the value, say payload format is json and argument value is XML, then ESB will convert even the argument value to json before inserting that value to the payload format.

How ever to identify XML for sure, we need to parse the value using XML parser which is pretty time consuming opertion(will reduce performance). So what this fix does is, add more checks rather than begin element to differentiate XML and if all of them passes, then only try with XML parser(which is called "deepCheck"). So in most cases it won't hit the parser, hence performance will not get affected(it will come to parser level when it comes to real XMLs). This is the default behavior.

So if the value is actually XML, then parser will get hit. So if you already know the value is XML, then there is an attribute so that you can manually skip hiting the XML parser(skipping deepCheck)
To do that what you have to do is add 'deepCheck="false"' attribute to the argument(sample argument would be <arg deepCheck="false" evaluator="xml" expression="ctx:abc"/>) which will skip deepChecking part.





Generated at Mon Aug 29 21:55:41 IST 2016 using JIRA 6.0.1#6096-sha1:e4a48bd73c6b8a4d99c824976ce5808b4c85857d.