[jira] [Commented] (DBCP-513) Hundreads of threads in Wait state with below stack trace
[ https://issues.apache.org/jira/browse/DBCP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569370#comment-16569370 ] HARSHIT AGARWAL commented on DBCP-513: -- Hi [~garydgregory] Pleas find attached patch to reproduce the issue. I have used Postgress SQL as I am using the same in production. Please let me know if any other information is required. Thanks This is the screen shot of the problem, app got hanged after 8th query. !Screen Shot 2018-08-05 at 10.29.52 AM.png! [^dbcpthread.zip] > Hundreads of threads in Wait state with below stack trace > - > > Key: DBCP-513 > URL: https://issues.apache.org/jira/browse/DBCP-513 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Java Version: > 1.8.0_121 > OS Complete Version: > Linux sdpvvrwm556 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST > 2017 x86_64 x86_64 x86_64 GNU/Linux > > DBCP Jar: > commons-dbcp2-2.1.1.jar >Reporter: Mahesh >Priority: Blocker > Attachments: Screen Shot 2018-08-05 at 10.29.52 AM.png, dbcpthread.zip > > > Hello Team, > Our application suddenly stops responding, when we checked thread dump, most > of the threads are in wait state with below stack trace, we had to restart > server to make it active, can you pelase provide your inputs on the root > cause & resolution? > > "JSockConn Thread #4532" #40906 prio=5 os_prio=0 tid=0x7f84382ce800 > nid=0xc692 waiting on condition [0x7f83d38f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c30a11b8> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) > at > org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) > at > org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DBCP-513) Hundreads of threads in Wait state with below stack trace
[ https://issues.apache.org/jira/browse/DBCP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] HARSHIT AGARWAL updated DBCP-513: - Attachment: Screen Shot 2018-08-05 at 10.29.52 AM.png > Hundreads of threads in Wait state with below stack trace > - > > Key: DBCP-513 > URL: https://issues.apache.org/jira/browse/DBCP-513 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Java Version: > 1.8.0_121 > OS Complete Version: > Linux sdpvvrwm556 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST > 2017 x86_64 x86_64 x86_64 GNU/Linux > > DBCP Jar: > commons-dbcp2-2.1.1.jar >Reporter: Mahesh >Priority: Blocker > Attachments: Screen Shot 2018-08-05 at 10.29.52 AM.png, dbcpthread.zip > > > Hello Team, > Our application suddenly stops responding, when we checked thread dump, most > of the threads are in wait state with below stack trace, we had to restart > server to make it active, can you pelase provide your inputs on the root > cause & resolution? > > "JSockConn Thread #4532" #40906 prio=5 os_prio=0 tid=0x7f84382ce800 > nid=0xc692 waiting on condition [0x7f83d38f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c30a11b8> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) > at > org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) > at > org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DBCP-513) Hundreads of threads in Wait state with below stack trace
[ https://issues.apache.org/jira/browse/DBCP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] HARSHIT AGARWAL updated DBCP-513: - Attachment: dbcpthread.zip > Hundreads of threads in Wait state with below stack trace > - > > Key: DBCP-513 > URL: https://issues.apache.org/jira/browse/DBCP-513 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Java Version: > 1.8.0_121 > OS Complete Version: > Linux sdpvvrwm556 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST > 2017 x86_64 x86_64 x86_64 GNU/Linux > > DBCP Jar: > commons-dbcp2-2.1.1.jar >Reporter: Mahesh >Priority: Blocker > Attachments: dbcpthread.zip > > > Hello Team, > Our application suddenly stops responding, when we checked thread dump, most > of the threads are in wait state with below stack trace, we had to restart > server to make it active, can you pelase provide your inputs on the root > cause & resolution? > > "JSockConn Thread #4532" #40906 prio=5 os_prio=0 tid=0x7f84382ce800 > nid=0xc692 waiting on condition [0x7f83d38f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c30a11b8> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) > at > org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) > at > org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DBCP-513) Hundreads of threads in Wait state with below stack trace
[ https://issues.apache.org/jira/browse/DBCP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569270#comment-16569270 ] Gary Gregory commented on DBCP-513: --- Hi [~agrrwal]: Can you provide a patch that reproduces the problem as a unit test? For a database, you should try to use an local database like H2 ([http://www.h2database.com/html/main.html)] or HSQLDB ([http://hsqldb.org/).] Otherwise, I do not see how I can help you in a timely manner. Thank you! Gary > Hundreads of threads in Wait state with below stack trace > - > > Key: DBCP-513 > URL: https://issues.apache.org/jira/browse/DBCP-513 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Java Version: > 1.8.0_121 > OS Complete Version: > Linux sdpvvrwm556 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST > 2017 x86_64 x86_64 x86_64 GNU/Linux > > DBCP Jar: > commons-dbcp2-2.1.1.jar >Reporter: Mahesh >Priority: Blocker > > Hello Team, > Our application suddenly stops responding, when we checked thread dump, most > of the threads are in wait state with below stack trace, we had to restart > server to make it active, can you pelase provide your inputs on the root > cause & resolution? > > "JSockConn Thread #4532" #40906 prio=5 os_prio=0 tid=0x7f84382ce800 > nid=0xc692 waiting on condition [0x7f83d38f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c30a11b8> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) > at > org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) > at > org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DBCP-513) Hundreads of threads in Wait state with below stack trace
[ https://issues.apache.org/jira/browse/DBCP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569260#comment-16569260 ] HARSHIT AGARWAL commented on DBCP-513: -- +1 Threads are going in wait state while fetching/get connection from pool, tried with 2.5.0 version as well. Thread dump: "qtp1150284200-22" #22 prio=5 os_prio=31 tid=0x7fc1e0a77800 nid=0x5f03 waiting on condition [0x751a2000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0006d7102ec0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:590) at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:441) at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:362) at org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) at org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1525) > Hundreads of threads in Wait state with below stack trace > - > > Key: DBCP-513 > URL: https://issues.apache.org/jira/browse/DBCP-513 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1 > Environment: Java Version: > 1.8.0_121 > OS Complete Version: > Linux sdpvvrwm556 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST > 2017 x86_64 x86_64 x86_64 GNU/Linux > > DBCP Jar: > commons-dbcp2-2.1.1.jar >Reporter: Mahesh >Priority: Blocker > > Hello Team, > Our application suddenly stops responding, when we checked thread dump, most > of the threads are in wait state with below stack trace, we had to restart > server to make it active, can you pelase provide your inputs on the root > cause & resolution? > > "JSockConn Thread #4532" #40906 prio=5 os_prio=0 tid=0x7f84382ce800 > nid=0xc692 waiting on condition [0x7f83d38f8000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0005c30a11b8> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at > org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:583) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:442) > at > org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) > at > org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:134) > at > org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1533) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JEXL-265) Ternary expression and namespace identifier grammar ambiguity leads to parsing error
[
https://issues.apache.org/jira/browse/JEXL-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569254#comment-16569254
]
Henri Biestro commented on JEXL-265:
HOW (0):
It's not possible to check at parsing time wether a namespace is actually valid
or not; solution must be syntax/grammar only.
HOW (1):
To remove the ambiguity and actually stick to identifier form, a namespace
identifier like 'x:y' will no longer allow spaces between the inner ':' and the
namespace 'x' and identifier 'y'. This way, the intention of using a namespace
is clear and the previous ambiguity removed.
With this solution, {{x?y:z()}} will generate an error...
> Ternary expression and namespace identifier grammar ambiguity leads to
> parsing error
>
>
> Key: JEXL-265
> URL: https://issues.apache.org/jira/browse/JEXL-265
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
> The workaround is to add parentheses around the right hand side {{(true) ? x
> : (abs(1))}} .
> The actual cause is that the grammar can not disambiguate between a correct
> ternary expression that uses a function call as right choice and one that
> uses a namespace function call as left choice {{x : abs(1)}} and misses the
> right hand choice, that latter case raising an exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JEXL-265) Ternary expression and namespace identifier grammar ambiguity leads to parsing error
[
https://issues.apache.org/jira/browse/JEXL-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-265:
---
Description:
A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
The workaround is to add parentheses around the right hand side {{(true) ? x :
(abs(1))}} .
The actual cause is that the grammar can not disambiguate between a correct
ternary expression that uses a function call as right choice and one that uses
a namespace function call as left choice {{x : abs(1)}} and misses the right
hand choice, that latter case raising an exception.
was:
A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
The workaround is to add parentheses around the right hand side {{(true) ? x :
(abs(1))}} .
The actual cause is that the grammar can not disambiguate between a correct
ternary expression that uses a function call as right choice and one that uses
a namespace function call as left choice {{x : abs(1)}} and misses the right
hand choice, that latter case raising an exception.
To remove the ambiguity and actually stick to identifier form, a namespace
identifier like 'x:y' will no longer allow spaces between the inner ':' and the
namespace 'x' and identifier 'y'. This way, the intention of using a namespace
is clear and the previous ambiguity removed.
> Ternary expression and namespace identifier grammar ambiguity leads to
> parsing error
>
>
> Key: JEXL-265
> URL: https://issues.apache.org/jira/browse/JEXL-265
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
> The workaround is to add parentheses around the right hand side {{(true) ? x
> : (abs(1))}} .
> The actual cause is that the grammar can not disambiguate between a correct
> ternary expression that uses a function call as right choice and one that
> uses a namespace function call as left choice {{x : abs(1)}} and misses the
> right hand choice, that latter case raising an exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JEXL-265) Ternary expression and namespace identifier grammar ambiguity leads to parsing error
[
https://issues.apache.org/jira/browse/JEXL-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-265:
---
Description:
A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
The workaround is to add parentheses around the right hand side {{(true) ? x :
(abs(1))}} .
The actual cause is that the grammar can not disambiguate between a correct
ternary expression that uses a function call as right choice and one that uses
a namespace function call as left choice {{x : abs(1)}} and misses the right
hand choice, that latter case raising an exception.
To remove the ambiguity and actually stick to identifier form, a namespace
identifier like 'x:y' will no longer allow spaces between the inner ':' and the
namespace 'x' and identifier 'y'. This way, the intention of using a namespace
is clear and the previous ambiguity removed.
was:
A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
The workaround is to add parentheses around the right hand side {{(true) ? x :
(abs(1))}} .
The actual cause though is that the grammar can not disambiguate between a
correct ternary expression that uses a function call as right choice and one
that uses a namespace function call as left choice {{x : abs(1)}} and misses
the right hand choice, that latter case raising an exception.
To remove the ambiguity and actually stick closer to identifier form, a
namespace identifier like x:y will no longer allow spaces between the inner ':'
and the namespace (x) and identifier (y). This way, the intention of using a
namespace is made clear
> Ternary expression and namespace identifier grammar ambiguity leads to
> parsing error
>
>
> Key: JEXL-265
> URL: https://issues.apache.org/jira/browse/JEXL-265
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
> The workaround is to add parentheses around the right hand side {{(true) ? x
> : (abs(1))}} .
> The actual cause is that the grammar can not disambiguate between a correct
> ternary expression that uses a function call as right choice and one that
> uses a namespace function call as left choice {{x : abs(1)}} and misses the
> right hand choice, that latter case raising an exception.
> To remove the ambiguity and actually stick to identifier form, a namespace
> identifier like 'x:y' will no longer allow spaces between the inner ':' and
> the namespace 'x' and identifier 'y'. This way, the intention of using a
> namespace is clear and the previous ambiguity removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JEXL-265) Ternary expression and namespace identifier grammar ambiguity leads to parsing error
Henri Biestro created JEXL-265:
--
Summary: Ternary expression and namespace identifier grammar
ambiguity leads to parsing error
Key: JEXL-265
URL: https://issues.apache.org/jira/browse/JEXL-265
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Henri Biestro
Assignee: Henri Biestro
Fix For: 3.2
A common expression like {{(true) ? x : abs(1)}} throws a parsing exception.
The workaround is to add parentheses around the right hand side {{(true) ? x :
(abs(1))}} .
The actual cause though is that the grammar can not disambiguate between a
correct ternary expression that uses a function call as right choice and one
that uses a namespace function call as left choice {{x : abs(1)}} and misses
the right hand choice, that latter case raising an exception.
To remove the ambiguity and actually stick closer to identifier form, a
namespace identifier like x:y will no longer allow spaces between the inner ':'
and the namespace (x) and identifier (y). This way, the intention of using a
namespace is made clear
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLI-288) Inconsistent parsing of unlimited option values
[
https://issues.apache.org/jira/browse/CLI-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569135#comment-16569135
]
NIRAJ RATHI commented on CLI-288:
-
The problem is the way JVM is converting input comand line argument to String
array.
{code:java}
public static void main(String[] args) throws Exception {
for ( String arg: args )
{
System.out.println(arg);
}
}
{code}
For command line cmd="less -opt2"
String array to main is [--cmd='less, -opt2'] instead of 3 Strings only 2 are
here.
For command line cmd "less -opt2"
String array to main is [--cmd, 'less, -opt2'] here we have 3 Strings.
Option parsing is based on String array prepared by JVM.
In case of second one DefaultParser treat -opt2 as unknown option.
> Inconsistent parsing of unlimited option values
> ---
>
> Key: CLI-288
> URL: https://issues.apache.org/jira/browse/CLI-288
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Adam Cardenas
>Priority: Major
>
> with the following configuration...
> {code:java}
> DefaultParser parser = new DefaultParser();
> Options opts = new Options();
> Option pager = Option.builder(null)
> .longOpt("cmd")
> .hasArg()
> .numberOfArgs(Option.UNLIMITED_VALUES)
> .build();
> opts.addOption(pager);
> {code}
>
> This works as long as the value of *cmd* is a single value.
> {code}
> $ myApp --cmd='less'
> {code}
> The following does not work, as soon as we add options to less
> {code}
> $ myApp --cmd='less -XFR'
> Exception in thread "main" com.cevaris.ag4j.cli.AppArgsException:
> org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -XFR
> at com.cevaris.ag4j.cli.ApacheAppArgs.parse(ApacheAppArgs.java:33)
> at com.cevaris.ag4j.Main.main(Main.java:61)
> Caused by: org.apache.commons.cli.UnrecognizedOptionException: Unrecognized
> option: -XFR
> at
> org.apache.commons.cli.DefaultParser.handleUnknownToken(DefaultParser.java:360)
> at
> org.apache.commons.cli.DefaultParser.handleConcatenatedOptions(DefaultParser.java:702)
> at
> org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:533)
> at
> org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:243)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:120)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:76)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:60)
> at com.cevaris.ag4j.cli.ApacheAppArgs.parse(ApacheAppArgs.java:31)'
> {code}
> The following works, as long as we use a space to separate option & value,
> rather than using an *=*
> {code}
> $ myApp --cmd 'less -XFR' # works
> $ myApp --cmd='less -XFR' # fails
> {code}
> Attempted to use *.valueSeparator()* with no luck.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
