[ESBJAVA-3632] Connector List UI Is not properly checked Created: 01/Apr/15  Updated: 01/Apr/15  Resolved: 01/Apr/15

Status: Resolved
Project: WSO2 ESB
Component/s: Cloud Connectors
Affects Version/s: 4.9.0 - M7
Fix Version/s: 4.9.0 - Alpha , 4.9.0

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

Attachments: PNG File Screen Shot 2015-04-01 at 8.27.42 AM.png    
Severity: Major
Estimated Complexity: Moderate
Test cases added: Yes

 Description   

If description is not there connector list does not properly arranged



 Comments   
Comment by Sivajothy Vanjikumaran [ 01/Apr/15 ]

https://github.com/wso2/carbon-mediation/pull/101





[ESBJAVA-3631] Connection timeout duration is not serializing correctly in the source view when it has a value like $timeDuration instead of an integer Created: 31/Mar/15  Updated: 31/Mar/15

Status: Open
Project: WSO2 ESB
Component/s: Templates
Affects Version/s: 4.8.1
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Sohani Weerasinghe Assignee: Kasun Indrasiri
Resolution: Unresolved 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   

When creating an Address Endpoint Template if we define a parameter as $timeDuration and if we are going to use that value for the duration in Connection Timeout it is not displaying properly.

The source view will look like

<template xmlns="http://ws.apache.org/ns/synapse" name="testTemplate">
<axis2ns12:parameter xmlns:axis2ns12="http://ws.apache.org/ns/synapse" name="timeDuration"></axis2ns12:parameter>
<endpoint name="$name">
<address uri="$uri">
<suspendOnFailure>
<progressionFactor>1.0</progressionFactor>
</suspendOnFailure>
<markForSuspension>
<retriesBeforeSuspension>0</retriesBeforeSuspension>
<retryDelay>0</retryDelay>
</markForSuspension>
<timeout>
<duration>30000</duration>
<responseAction>discard</responseAction>
</timeout>
</address>
</endpoint>
</template>

The duration tag should be <duration>$timeDuration</duration>

If we check in the file system, the source is getting serialized properly and the main source view also updates properly but the source view of the Address Endpoint Template is not getting updated






[ESBJAVA-3630] Inbound file endpoints should be able to do ordering based on various ordering strategies (fifo, file name etc.) Created: 31/Mar/15  Updated: 01/Apr/15

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

Type: Improvement Priority: High
Reporter: Malaka Silva Assignee: Malaka Silva
Resolution: Unresolved 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




[ESBJAVA-3629] [Entitlement Mediator] Session reuse is not handled properly in Thrift client Created: 30/Mar/15  Updated: 30/Mar/15

Status: Open
Project: WSO2 ESB
Component/s: Mediators
Affects Version/s: 4.8.1
Fix Version/s: None

Type: Bug Priority: Highest
Reporter: Omindu Rathnaweera Assignee: Omindu Rathnaweera
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

Steps to reproduce:

  • Setup the entitlement mediator for an ESB proxy service
  • Invoke the proxy service once
  • Invoke the service for the second time after 30+ minutes (Session ID invalidates after 30 minutes idle time)
  • The following exception can be seen in ESB console

TID: [0] [ocessor-17] [ESB] [2015-03-25 18:15:56,778] ERROR

{org.wso2.carbon.identity.entitlement.mediator.EntitlementMediator}
  • Error occurred while evaluating the policy {org .wso2.carbon.identity.entitlement.mediator.EntitlementMediator}

    org.wso2.carbon.identity.entitlement.proxy.exception.EntitlementProxyException: Error while getting decision from PDP using ThriftEntitlementServiceClient
    at org.wso2.carbon.identity.entitlement.proxy.thrift.ThriftEntitlementServiceClient.getDecision(ThriftEntitlementServiceClient.java:130)
    at org.wso2.carbon.identity.entitlement.proxy.thrift.ThriftEntitlementServiceClient.getDecision(ThriftEntitlementServiceClient.java:64)
    at org.wso2.carbon.identity.entitlement.proxy.PEPProxy.getDecision(PEPProxy.java:83)
    at org.wso2.carbon.identity.entitlement.proxy.PEPProxy.getDecision(PEPProxy.java:54)
    at org.wso2.carbon.identity.entitlement.mediator.EntitlementMediator.mediate(EntitlementMediator.java:167)
    at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:74)
    at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:44)
    at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:135)
    at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:200)
    at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:74)
    at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:44)
    at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:135)
    at org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:166)
    at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
    at org.apache.synapse.transport.passthru.ServerWorker.processEntityEnclosingRequest(ServerWorker.java:411)
    at org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:183)
    at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
    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)
    Caused by: EntitlementException(message:Error occurred when invoking the Thrift based Entitlement Service.)
    at org.wso2.carbon.identity.entitlement.proxy.generatedCode.EntitlementThriftClient$getDecision_result.read(EntitlementThriftClient.java:882)
    at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
    at org.wso2.carbon.identity.entitlement.proxy.generatedCode.EntitlementThriftClient$Client.recv_getDecision(EntitlementThriftClient.java:63)
    at org.wso2.carbon.identity.entitlement.proxy.generatedCode.EntitlementThriftClient$Client.getDecision(EntitlementThriftClient.java:51)
    at org.wso2.carbon.identity.entitlement.proxy.thrift.ThriftEntitlementServiceClient.getDecision(ThriftEntitlementServiceClient.java:126)
    ... 19 more



 Comments   
Comment by Omindu Rathnaweera [ 30/Mar/15 ]

When the ThriftEntitlementServiceClient calls to IS to get the evaluation for a XACML request, the session ID for the authentication is passed along with the XACML request. If the time difference between 2 calls to the IS from ESB is more than 30 minutes, IS considers the particular session ID as invalid and throws an exception. The previously mentioned exception occurs when ThriftEntitlementServiceClient sends the XACML request with the expired session ID.





[ESBJAVA-3628] VFS Distributed Lock is not working as expected Created: 30/Mar/15  Updated: 30/Mar/15  Due: 30/Mar/15  Resolved: 30/Mar/15

Status: Resolved
Project: WSO2 ESB
Component/s: Inbound Endpoints
Affects Version/s: 4.9.0 - M7
Fix Version/s: 4.9.0 - Alpha

Type: Bug Priority: Highest
Reporter: Malaka Silva Assignee: Malaka Silva
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: Not-applicable

 Description   

Use the following configuration in cluster setup with 2 or ore workers.

<inboundEndpoint xmlns="http://ws.apache.org/ns/synapse"
name="file"
sequence="request"
onError="fault"
protocol="file"
suspend="false">
<parameters>
<parameter name="interval">1000</parameter>
<parameter name="coordination">false</parameter>
<parameter name="transport.vfs.ActionAfterErrors">NONE</parameter>
<parameter name="transport.vfs.ContentType">test/xml</parameter>
<parameter name="transport.vfs.LockReleaseSameNode">false</parameter>
<parameter name="transport.vfs.AutoLockRelease">false</parameter>
<parameter name="transport.vfs.ActionAfterFailure">NONE</parameter>
<parameter name="transport.vfs.ActionAfterProcess">MOVE</parameter>
<parameter name="sequential">true</parameter>
<parameter name="transport.vfs.FileURI">file:///home/malaka/work/pack/m7/vfs/files/in</parameter>
<parameter name="transport.vfs.DistributedLock">true</parameter>
<parameter name="transport.vfs.MoveAfterProcess">file:///home/malaka/work/pack/m7/vfs/files/out</parameter>
<parameter name="transport.vfs.Locking">enable</parameter>
</parameters>
</inboundEndpoint>

Will see error when multiple nodes trying to work on same file.



 Comments   
Comment by Malaka Silva [ 30/Mar/15 ]

https://github.com/wso2/carbon-mediation/commit/c8d58e6ce904250f9c84a79b81cd3cbdb0ddf5e3





[ESBJAVA-3627] coordination is not saved via inbound ui Created: 30/Mar/15  Updated: 30/Mar/15  Resolved: 30/Mar/15

Status: Resolved
Project: WSO2 ESB
Component/s: None
Affects Version/s: 4.9.0 - M7
Fix Version/s: 4.9.0 - Alpha

Type: Bug Priority: High
Reporter: Malaka Silva Assignee: Malaka Silva
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

 Comments   
Comment by Malaka Silva [ 30/Mar/15 ]

https://github.com/wso2/carbon-mediation/commit/b469b78aed934a85e0117529ec9c1adc00e0057f





[ESBJAVA-3626] A Connection Leak in JMS Transport Created: 29/Mar/15  Updated: 01/Apr/15

Status: In Progress
Project: WSO2 ESB
Component/s: None
Affects Version/s: 4.8.1
Fix Version/s: 4.9.0

Type: Bug Priority: Highest
Reporter: Hasitha Abeykoon Assignee: shafreen anfar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux/Windows


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   

Consider a scenario where we have a ESB cluster and one activeMQ node
Say ESB worker nodes are W1, W2 and W3.

We deploy a CAR file which is connecting to a durable topic using clientID=x

1. W1 node creates a connection with the broker successfully. It can consume the messages.
2. W2, W3 nodes are trying to create a subscriptions using same clientID=x and they fail because it already has a consumer registered.

Now, W1 and W2 nodes continuously give the exception re-trying to subscribe. It does not close the connection when re-try. At the end of the day, ESB runs OOM. At that moment we cannot access the management (to undeploy the CAR) console as well.



 Comments   
Comment by Hasitha Abeykoon [ 29/Mar/15 ]

Found the culprit here.

kernel/branches/4.2.0/patches/patch0005/dependencies/transports/modules/jms/src/main/java/org/apache/axis2/transport/jms/JMSUtils.java

public static Connection createConnection(ConnectionFactory conFac,
String user, String pass, boolean jmsSpec11, Boolean isQueue,
boolean isDurable, String clientID) throws JMSException {

Connection connection = null;
if (log.isDebugEnabled())

{ log.debug("Creating a " + (isQueue == null ? "Generic" : isQueue ? "Queue" : "Topic") + "Connection using credentials : (" + user + "/" + pass + ")"); }

if (jmsSpec11 || isQueue == null) {
if (user != null && pass != null)

{ connection = conFac.createConnection(user, pass); }

else

{ connection = conFac.createConnection(); }

if(isDurable)

{ connection.setClientID(clientID); }

} else {
QueueConnectionFactory qConFac = null;
TopicConnectionFactory tConFac = null;
if (isQueue) { qConFac = (QueueConnectionFactory) conFac; } else {

.......


Here
if(isDurable){ connection.setClientID(clientID); }

Throws an exception an the created connection is never closed. Te-try happens in a continuous loop and connections are never cleared.





[ESBJAVA-3625] Car file deployment with wrong JMS configurations make server unresponsive Created: 29/Mar/15  Updated: 29/Mar/15

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

Type: Bug Priority: Highest
Reporter: Hasitha Abeykoon Assignee: Kasun Indrasiri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux/Windows


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: Not-applicable

 Description   

Steps to reproduce.
Observed in ESB 4.8.1

1. Create a JMS listening proxy service with wrong JMS configurations. Basically put a non-existing broker url (in axis2.xml).
2. Make a CAR file out of it
3. Deploy the car file

This will cause following logs at broker side. These logs continuously prints.
At that time management console is also not accessible. If we consider a ESB cluster, the whole cluster becomes un-responsive if we deploy a CAR file like that. Also, a single CAR file deployment failure should not make the Mgt Console un-responsive.

TID: [0] [ESB] [2015-03-24 15:48:32,722] ERROR

{org.apache.axis2.transport.jms.JMSListener} - Unable to continue server startup as it seems the JMS Provider is not yet started. Please start the JMS provider now. {org.apache.axis2.transport.jms.JMSListener}

TID: [0] [ESB] [2015-03-24 15:48:32,723] ERROR

{org.apache.axis2.transport.jms.JMSListener} - Connection attempt : 1 for JMS Provider failed. Next retry in 20 seconds {org.apache.axis2.transport.jms.JMSListener}

TID: [0] [ESB] [2015-03-24 15:48:52,725] ERROR

{org.apache.axis2.transport.jms.JMSListener} - Unable to continue server startup as it seems the JMS Provider is not yet started. Please start the JMS provider now. {org.apache.axis2.transport.jms.JMSListener}




[ESBJAVA-3624] JSON response being generated is not putting numbers in double quotes e.g. 1234 should be "1234". But it puts the numbers starting with 0 in double quotes e.g. "025". String "true" and "false" appear as true and false keywords without double quotes. Created: 27/Mar/15  Updated: 27/Mar/15

Status: Open
Project: WSO2 ESB
Component/s: Mediators
Affects Version/s: 4.8.0
Fix Version/s: None

Type: Bug Priority: High
Reporter: Gagandeep S Assignee: Kasun Indrasiri
Resolution: Unresolved Votes: 0
Labels: ESB
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

Windows 7


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
Affects Docs:
Yes

 Comments   
Comment by Gagandeep S [ 27/Mar/15 ]

{"profile": {
"indicator": false,
"deliveryZipDetails": {"deliveryZipDetail": [

{ "zip": 51010 }

,

{ "zip": "01234" }]}

,
"telephoneDetails": {"telephoneDetail": [

{ "type": "dayPhone", "number": 2344232342 }

,

{ "type": "eveningPhone", "number": 2222222222 }

]}
}}





[ESBJAVA-3623] ESB not processing some of the responses received from back end service Created: 25/Mar/15  Updated: 25/Mar/15

Status: Open
Project: WSO2 ESB
Component/s: Transport
Affects Version/s: 4.8.1
Fix Version/s: None

Type: Bug Priority: High
Reporter: Asitha Nanayakkara Assignee: Kasun Indrasiri
Resolution: Unresolved Votes: 0
Labels: ESB
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 6.6
Oracle jdk 1.7.0_75
4GB RAM
2vCPU
10GB drive
Run within VirtualBox


Attachments: Zip Archive configs.zip    
Severity: Major
Estimated Complexity: Advanced
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   

Setup

There is a service in DSS fronted by an ESB proxy service . When a request is sent from ESB proxy to DSS, response is received. But on some occasions ESB timeouts, not receiving the response from DSS in time. When we check the wire logs on ESB, response is not received from DSS. When we look at the packets through Wireshark we observe that the actual response was sent from DSS in time. But in ESB transport level the response in not processed. This happens intermittently in the given environment with the attached configurations.






Generated at Wed Apr 01 14:53:42 IST 2015 using JIRA 6.0.1#6096-sha1:e4a48bd73c6b8a4d99c824976ce5808b4c85857d.