[jira] [Resolved] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[
https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-416.
Resolution: Fixed
issue resolved according to
[r1306016|http://svn.apache.org/viewvc?view=revisionrevision=1306016] by
Claudio - well done, mate!
Improve DFS/BFS visit detecting multiple states and related actions instead
of just stop/continue
-
Key: SANDBOX-416
URL: https://issues.apache.org/jira/browse/SANDBOX-416
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Claudio Squarcella
As discussed in
[ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E],
{{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return
{{boolean}} flags can be sometimes not so intuitive.
The proposal is replacing {{boolean}} flags return statements with an
enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify
* visit has to be immediately terminated
* visit can continue;
* current node children visit can be skipped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240283#comment-13240283
]
Nicola Barbiero commented on LANG-796:
--
That's the point: DateUtils.addDays receives in input a Date, that is an
absolute time, so it should not be influenced by DST. Using a Calendar
configured for the UTC timezone means to not use DateUtils.addDays, since there
is no overloading method that receives a Calendar in input.
As Thomas said, the method uses internally the default Calendar instance, that
is set to the local timezone of the server where the code is running, and this
is quite problematic in those time of cloud computing, because the code will
work differently if the server is located in a zone where DST is applied or not
(some countries do not implement any DST at all).
Summarizing, for me the issue is that the user of this method is affected by
the TimeZone but he has no way to set this TimeZone, because always the default
Calendar instance and the local timezone are used.
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new
object. The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[]
{ dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime()
equals to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime()
equals to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects,
for example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JXPATH-155) iteratePointers give the wrong pointers
iteratePointers give the wrong pointers
---
Key: JXPATH-155
URL: https://issues.apache.org/jira/browse/JXPATH-155
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Environment: jdk 1.5
Reporter: Martin Busch
I have a xml structur like these:
Request
Tarifierung
Verkaufsprodukt
Produkt
Kondition
Wert2/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert3/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert6/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert16/Wert
Werteinheit10/Werteinheit
/Kondition
/Produkt
/Verkaufsprodukt
/Tarifierung
/Request
I get an iterator for the Kondtion tags:
JXPathContext context = JXPathContext.newContext(in);
IteratorPointer it_konditionen = (IteratorPointer)
context.iteratePointers(/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition);
while (it_konditionen != null it_konditionen.hasNext()) {
Pointer p = it_konditionen.next();
System.out.println(p);
}
The output to System.out looks like:
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[1]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
As we can see it start with [2] (which is not the problem) but it iterates over
2-4 twice! And this IS a problem.
Very strange is that the call of it_konditionen.hasNext() increase the
iterator one step.
Best regards
Martin Busch
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JXPATH-155) iteratePointers give the wrong pointers
[
https://issues.apache.org/jira/browse/JXPATH-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Busch updated JXPATH-155:
Description:
I have a xml structur like these:
{code:xml}
Request
Tarifierung
Verkaufsprodukt
Produkt
Kondition
Wert2/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert3/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert6/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert16/Wert
Werteinheit10/Werteinheit
/Kondition
/Produkt
/Verkaufsprodukt
/Tarifierung
/Request
{code}
I get an iterator for the Kondtion tags:
{code:java}
JXPathContext context = JXPathContext.newContext(in);
IteratorPointer it_konditionen = (IteratorPointer)
context.iteratePointers(/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition);
while (it_konditionen != null it_konditionen.hasNext()) {
Pointer p = it_konditionen.next();
System.out.println(p);
}
{code}
The output to System.out looks like:
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[1]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
As we can see it start with [2] (which is not the problem) but it iterates over
2-4 twice! And this IS a problem.
Very strange is that the call of it_konditionen.hasNext() increase the
iterator one step.
Best regards
Martin Busch
was:
I have a xml structur like these:
Request
Tarifierung
Verkaufsprodukt
Produkt
Kondition
Wert2/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert3/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert6/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert16/Wert
Werteinheit10/Werteinheit
/Kondition
/Produkt
/Verkaufsprodukt
/Tarifierung
/Request
I get an iterator for the Kondtion tags:
JXPathContext context = JXPathContext.newContext(in);
IteratorPointer it_konditionen = (IteratorPointer)
context.iteratePointers(/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition);
while (it_konditionen != null it_konditionen.hasNext()) {
Pointer p = it_konditionen.next();
System.out.println(p);
}
The output to System.out looks like:
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[1]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
As we can see it start with [2] (which is not the problem) but it iterates over
2-4 twice! And this IS a problem.
Very strange is that the call of it_konditionen.hasNext() increase the
iterator one step.
Best regards
Martin Busch
iteratePointers give the wrong pointers
---
Key: JXPATH-155
URL: https://issues.apache.org/jira/browse/JXPATH-155
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Environment: jdk 1.5
Reporter: Martin Busch
I have a xml structur like these:
{code:xml}
Request
Tarifierung
Verkaufsprodukt
Produkt
[jira] [Commented] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[
https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240303#comment-13240303
]
Claudio Squarcella commented on SANDBOX-416:
Hi,
I saw you implemented the proposed improvements before I had the time to do so
myself. Thanks for that! :)
Ciao,
Claudio
Improve DFS/BFS visit detecting multiple states and related actions instead
of just stop/continue
-
Key: SANDBOX-416
URL: https://issues.apache.org/jira/browse/SANDBOX-416
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Claudio Squarcella
As discussed in
[ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E],
{{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return
{{boolean}} flags can be sometimes not so intuitive.
The proposal is replacing {{boolean}} flags return statements with an
enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify
* visit has to be immediately terminated
* visit can continue;
* current node children visit can be skipped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-137) Main documentation page links wrong javadocs
Main documentation page links wrong javadocs Key: CODEC-137 URL: https://issues.apache.org/jira/browse/CODEC-137 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Chrome 18, but I guess any browser Reporter: Karsten Tinnefeld Priority: Minor http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but in fact links 1.4 javadocs. Thus, some prominent new features are not properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-137) Main documentation page links wrong javadocs
[ https://issues.apache.org/jira/browse/CODEC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240351#comment-13240351 ] Sebb commented on CODEC-137: As a work-round the current Javadocs (i.e. 1.6) are available from the Javadoc (SVN latest) at present. Main documentation page links wrong javadocs Key: CODEC-137 URL: https://issues.apache.org/jira/browse/CODEC-137 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Chrome 18, but I guess any browser Reporter: Karsten Tinnefeld Priority: Minor Labels: documentation Original Estimate: 1h Remaining Estimate: 1h http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but in fact links 1.4 javadocs. Thus, some prominent new features are not properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-84) Clarify comment handling
[ https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-84. - Resolution: Fixed Fixed test case, docs and code Clarify comment handling Key: CSV-84 URL: https://issues.apache.org/jira/browse/CSV-84 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Fix For: 1.0 Comment handling is not currently fully documented / tested. There are several possible situations: 1) trailing comment following one or more values 2) comment marker starts in the first column 3) comment marker starts in the first non-whitespace column How should these be handled? 1) The trailing comment should be ignored 2) Entire line should be ignored, i.e. don't treat it as a blank line 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat as 1, i.e. there is a single value containing whitespace It might also be useful to consider returning comments to the application program as part of CSVRecord. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
ManagedDataSource returns uses the same underlying DB connection across JTA tx -- Key: DBCP-378 URL: https://issues.apache.org/jira/browse/DBCP-378 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Ortwin Glück Priority: Critical It seems that when more than one JTA transaction is used within the same thread (suspend/resume transaction), the ManagedDataSource always uses the same underlying DB connection. This scenario is common in EJB containers! If the same DB connection is used the JTA suspend/resume actions have no effect. The JTA semantics is violated this behaviour. Use the following code to setup a unit test that works in your environment // DS setup XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource(); ... TransactionManager tm = ... DataSourceXAConnectionFactory cf = new DataSourceXAConnectionFactory(tm, ods); AbandonedConfig ab = new AbandonedConfig(); ab.setLogAbandoned(false); ab.setRemoveAbandoned(true); ab.setRemoveAbandonedTimeout(15*60); connPool = new GenericObjectPool(null); // registers itself on the pool KeyedObjectPoolFactory stmtPool = = new StackKeyedObjectPoolFactory(5); new PoolableManagedConnectionFactory(cf, connPool, stmtPool, null, 5, (CollectionString) null, // init sql false, // read-only false, // auto-commit Connection.TRANSACTION_READ_COMMITTED, (String) null, // catalog ab); ds = new ManagedDataSource(connPool, cf.getTransactionRegistry()); // Unit test tm.begin(); Connection c1 = source.getConnection(); Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); c1.close(); Transaction tx = tm.suspend(); tm.begin(); c2 = source.getConnection(); ic2 = ((ManagedConnection) c2).getInnermostDelegate(); c2.close(); assertNotSame(Pool must NOT use identical connection across tx, ic1, ic2); tm.commit(); tm.resume(tx); tm.commit(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-136) Use Charset objects when possible, create Charsets class for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated CODEC-136: -- Summary: Use Charset objects when possible, create Charsets class for required character encodings (was: Use Charset objects when possible, create Charsets for required character encodings) Use Charset objects when possible, create Charsets class for required character encodings - Key: CODEC-136 URL: https://issues.apache.org/jira/browse/CODEC-136 Project: Commons Codec Issue Type: New Feature Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 1.7 Use Charset objects when possible, create Charsets for required character encodings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-136) Use Charset objects when possible, create Charsets class for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-136. --- Resolution: Fixed In svn. Use Charset objects when possible, create Charsets class for required character encodings - Key: CODEC-136 URL: https://issues.apache.org/jira/browse/CODEC-136 Project: Commons Codec Issue Type: New Feature Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 1.7 Use Charset objects when possible, create Charsets for required character encodings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-797) StringEscapeUtils.escapeJson
StringEscapeUtils.escapeJson Key: LANG-797 URL: https://issues.apache.org/jira/browse/LANG-797 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.6 Reporter: Joe Littlejohn Priority: Minor It would be great to offer a StringEscapeUtils.escapeJson method which is similar to StringEscapeUtils.escapeJavaScript but will not escape apostrophe (single-quote) chars. The current escapeJavaScript method does escape single-quote chars, but this produces invalid JSON. A good description of the problem can be found here: http://stackoverflow.com/questions/2275359/jquery-single-quote-in-json-response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240530#comment-13240530
]
Thomas Neidhart commented on CODEC-96:
--
I have reviewed the patch, which looks good in general, just a few minor things
I have noticed:
* BaseNCodec has a member xcontext which is never used
* some fields in the Context class are protected, others package private
* for the BaseNCodecInputStream, the mark/markSupported/reset methods should
be implemented, see below
We may opt for not supporting it:
* mark does nothing
* markSupported returns false
* reset throws IOException
That would mimick the InflaterInputStream, otoh we could support it like that:
* markSupported: depends on the underlying stream
* mark: if supported, saves the context, and marks underlying stream
* reset: restores the context and resets underlying stream
Thomas
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240542#comment-13240542
]
Sebb commented on CODEC-96:
---
bq. BaseNCodec has a member xcontext which is never used
Sorry, looks like a bit of debug code I left in
bq. some fields in the Context class are protected, others package private
Should probably all be package private
I'll create an amended patch.
bq. for the BaseNCodecInputStream, the mark/markSupported/reset methods should
be implemented
That's a separate issue; this patch only addresses the thread-safety aspects.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
[ https://issues.apache.org/jira/browse/DBCP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ortwin Glück resolved DBCP-378. --- Resolution: Invalid ManagedDataSource behaves correctly. The test is wrong (it compares null with null) ManagedDataSource returns uses the same underlying DB connection across JTA tx -- Key: DBCP-378 URL: https://issues.apache.org/jira/browse/DBCP-378 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Ortwin Glück Priority: Critical It seems that when more than one JTA transaction is used within the same thread (suspend/resume transaction), the ManagedDataSource always uses the same underlying DB connection. This scenario is common in EJB containers! If the same DB connection is used the JTA suspend/resume actions have no effect. The JTA semantics is violated this behaviour. Use the following code to setup a unit test that works in your environment // DS setup XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource(); ... TransactionManager tm = ... DataSourceXAConnectionFactory cf = new DataSourceXAConnectionFactory(tm, ods); AbandonedConfig ab = new AbandonedConfig(); ab.setLogAbandoned(false); ab.setRemoveAbandoned(true); ab.setRemoveAbandonedTimeout(15*60); connPool = new GenericObjectPool(null); // registers itself on the pool KeyedObjectPoolFactory stmtPool = = new StackKeyedObjectPoolFactory(5); new PoolableManagedConnectionFactory(cf, connPool, stmtPool, null, 5, (CollectionString) null, // init sql false, // read-only false, // auto-commit Connection.TRANSACTION_READ_COMMITTED, (String) null, // catalog ab); ds = new ManagedDataSource(connPool, cf.getTransactionRegistry()); // Unit test tm.begin(); Connection c1 = source.getConnection(); Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); c1.close(); Transaction tx = tm.suspend(); tm.begin(); c2 = source.getConnection(); ic2 = ((ManagedConnection) c2).getInnermostDelegate(); c2.close(); assertNotSame(Pool must NOT use identical connection across tx, ic1, ic2); tm.commit(); tm.resume(tx); tm.commit(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-137) Main documentation page links wrong javadocs
[ https://issues.apache.org/jira/browse/CODEC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240562#comment-13240562 ] Gary D. Gregory commented on CODEC-137: --- The link should have said 1.6, not 1.5, for 1.7 it will say 1.7. Older Javadocs will not be referenced. Main documentation page links wrong javadocs Key: CODEC-137 URL: https://issues.apache.org/jira/browse/CODEC-137 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Chrome 18, but I guess any browser Reporter: Karsten Tinnefeld Priority: Minor Labels: documentation Original Estimate: 1h Remaining Estimate: 1h http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but in fact links 1.4 javadocs. Thus, some prominent new features are not properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240566#comment-13240566
]
Thomas Neidhart commented on CODEC-96:
--
{quote}
That's a separate issue; this patch only addresses the thread-safety aspects.
{quote}
That's true, I just realised that problem when reviewing your patch. Should we
create a new issue, or fix it together?
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CODEC-96:
--
Attachment: CODEX-96-2.patch
Supersedes CODEX-96.patch
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-213) _numActive can go negative
_numActive can go negative -- Key: POOL-213 URL: https://issues.apache.org/jira/browse/POOL-213 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Mark Mindenhall I'm working on a project that uses Hector (Cassandra client). Hector uses commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra cluster. Hector provides a JMX MBean that exposes a NumActive property, which is the cumulative call to retrieve numActive from all of the individual connection pools. When querying this property via JMS on our production servers, we often see negative values. For example, on a server that has three connection pools, the NumActive property reported was -3899. I know this issue has been reported before (POOL-29), and was supposedly fixed. The fix discussed there was to merely check the value of _numActive to prevent it from going negative. However, that does not fix the real problem here, which is that it is possible to decrement _numActive more than once for each activated object. For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) Create a pool with 10 objects. 2) Borrow all 10 objects from the pool. 3) Call getNumActive (returns 10). 4) Call invalidateObject for ONE of the objects 11 times. 5) Call getNumActive (returns -1). The invalidateObject method calls the _factory to destroy the object, and subsequent calls to destroy the same object may or may not result in an exception. Regardless, _numActive is decremented within a finally block, and therefore would always be decremented even if the object had already been invalidated and destroyed. I'd like to suggest using a HashSet instead of a counter to keep track of active objects. If borrowing an object added it to a HashSet, and returning or invaliding the object removed it from the HashSet (subsequent removes would be no-ops), the example given above would not result in an incorrect value when getNumActive is called (it would just return the current size of the HashSet). Note that although unrelated to this bug, it might also be wise to use a HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240626#comment-13240626 ] Gary D. Gregory commented on POOL-213: -- Can you try the latest version (1.6)? _numActive can go negative -- Key: POOL-213 URL: https://issues.apache.org/jira/browse/POOL-213 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Mark Mindenhall I'm working on a project that uses Hector (Cassandra client). Hector uses commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra cluster. Hector provides a JMX MBean that exposes a NumActive property, which is the cumulative call to retrieve numActive from all of the individual connection pools. When querying this property via JMS on our production servers, we often see negative values. For example, on a server that has three connection pools, the NumActive property reported was -3899. I know this issue has been reported before (POOL-29), and was supposedly fixed. The fix discussed there was to merely check the value of _numActive to prevent it from going negative. However, that does not fix the real problem here, which is that it is possible to decrement _numActive more than once for each activated object. For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) Create a pool with 10 objects. 2) Borrow all 10 objects from the pool. 3) Call getNumActive (returns 10). 4) Call invalidateObject for ONE of the objects 11 times. 5) Call getNumActive (returns -1). The invalidateObject method calls the _factory to destroy the object, and subsequent calls to destroy the same object may or may not result in an exception. Regardless, _numActive is decremented within a finally block, and therefore would always be decremented even if the object had already been invalidated and destroyed. I'd like to suggest using a HashSet instead of a counter to keep track of active objects. If borrowing an object added it to a HashSet, and returning or invaliding the object removed it from the HashSet (subsequent removes would be no-ops), the example given above would not result in an incorrect value when getNumActive is called (it would just return the current size of the HashSet). Note that although unrelated to this bug, it might also be wise to use a HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240652#comment-13240652 ] Mark Mindenhall commented on POOL-213: -- It looks like 1.6 would solve the problem, but using 1.6 would require me to refactor the Hector code to use generics. _numActive can go negative -- Key: POOL-213 URL: https://issues.apache.org/jira/browse/POOL-213 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Mark Mindenhall I'm working on a project that uses Hector (Cassandra client). Hector uses commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra cluster. Hector provides a JMX MBean that exposes a NumActive property, which is the cumulative call to retrieve numActive from all of the individual connection pools. When querying this property via JMS on our production servers, we often see negative values. For example, on a server that has three connection pools, the NumActive property reported was -3899. I know this issue has been reported before (POOL-29), and was supposedly fixed. The fix discussed there was to merely check the value of _numActive to prevent it from going negative. However, that does not fix the real problem here, which is that it is possible to decrement _numActive more than once for each activated object. For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) Create a pool with 10 objects. 2) Borrow all 10 objects from the pool. 3) Call getNumActive (returns 10). 4) Call invalidateObject for ONE of the objects 11 times. 5) Call getNumActive (returns -1). The invalidateObject method calls the _factory to destroy the object, and subsequent calls to destroy the same object may or may not result in an exception. Regardless, _numActive is decremented within a finally block, and therefore would always be decremented even if the object had already been invalidated and destroyed. I'd like to suggest using a HashSet instead of a counter to keep track of active objects. If borrowing an object added it to a HashSet, and returning or invaliding the object removed it from the HashSet (subsequent removes would be no-ops), the example given above would not result in an incorrect value when getNumActive is called (it would just return the current size of the HashSet). Note that although unrelated to this bug, it might also be wise to use a HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240654#comment-13240654 ] Gary D. Gregory commented on POOL-213: -- You can just replace the 1.5 jar with the 1.6 jar without changing any source code. _numActive can go negative -- Key: POOL-213 URL: https://issues.apache.org/jira/browse/POOL-213 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Mark Mindenhall I'm working on a project that uses Hector (Cassandra client). Hector uses commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra cluster. Hector provides a JMX MBean that exposes a NumActive property, which is the cumulative call to retrieve numActive from all of the individual connection pools. When querying this property via JMS on our production servers, we often see negative values. For example, on a server that has three connection pools, the NumActive property reported was -3899. I know this issue has been reported before (POOL-29), and was supposedly fixed. The fix discussed there was to merely check the value of _numActive to prevent it from going negative. However, that does not fix the real problem here, which is that it is possible to decrement _numActive more than once for each activated object. For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) Create a pool with 10 objects. 2) Borrow all 10 objects from the pool. 3) Call getNumActive (returns 10). 4) Call invalidateObject for ONE of the objects 11 times. 5) Call getNumActive (returns -1). The invalidateObject method calls the _factory to destroy the object, and subsequent calls to destroy the same object may or may not result in an exception. Regardless, _numActive is decremented within a finally block, and therefore would always be decremented even if the object had already been invalidated and destroyed. I'd like to suggest using a HashSet instead of a counter to keep track of active objects. If borrowing an object added it to a HashSet, and returning or invaliding the object removed it from the HashSet (subsequent removes would be no-ops), the example given above would not result in an incorrect value when getNumActive is called (it would just return the current size of the HashSet). Note that although unrelated to this bug, it might also be wise to use a HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[ https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240660#comment-13240660 ] Mark Mindenhall commented on POOL-213: -- Thanks, I'll try that...I figured something would break if I just dropped in the generics version. _numActive can go negative -- Key: POOL-213 URL: https://issues.apache.org/jira/browse/POOL-213 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Mark Mindenhall I'm working on a project that uses Hector (Cassandra client). Hector uses commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra cluster. Hector provides a JMX MBean that exposes a NumActive property, which is the cumulative call to retrieve numActive from all of the individual connection pools. When querying this property via JMS on our production servers, we often see negative values. For example, on a server that has three connection pools, the NumActive property reported was -3899. I know this issue has been reported before (POOL-29), and was supposedly fixed. The fix discussed there was to merely check the value of _numActive to prevent it from going negative. However, that does not fix the real problem here, which is that it is possible to decrement _numActive more than once for each activated object. For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) Create a pool with 10 objects. 2) Borrow all 10 objects from the pool. 3) Call getNumActive (returns 10). 4) Call invalidateObject for ONE of the objects 11 times. 5) Call getNumActive (returns -1). The invalidateObject method calls the _factory to destroy the object, and subsequent calls to destroy the same object may or may not result in an exception. Regardless, _numActive is decremented within a finally block, and therefore would always be decremented even if the object had already been invalidated and destroyed. I'd like to suggest using a HashSet instead of a counter to keep track of active objects. If borrowing an object added it to a HashSet, and returning or invaliding the object removed it from the HashSet (subsequent removes would be no-ops), the example given above would not result in an incorrect value when getNumActive is called (it would just return the current size of the HashSet). Note that although unrelated to this bug, it might also be wise to use a HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-248) jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
---
Key: DAEMON-248
URL: https://issues.apache.org/jira/browse/DAEMON-248
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.0.2
Reporter: Elias Ross
Run a process using jsvc.exec
Then use the Attach API to locate the process.
Note that java.rt.vmArgs are not available. See the attached program.
monitoredhost = MonitoredHost.getMonitoredHost(new
HostIdentifier((String) null));
set = monitoredhost.activeVms();
... iterate
MonitoredVm monitoredvm = monitoredhost.getMonitoredVm(new
VmIdentifier(s));
ListMonitor l = monitoredvm.findByPattern(.*);
for (Monitor m : l) {
System.out.println( + m.getName() + +
m.getValue());
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-248) jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
[
https://issues.apache.org/jira/browse/DAEMON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240711#comment-13240711
]
Elias Ross commented on DAEMON-248:
---
Basically, the bug is a request. I need another way to attach to these
processes.
It might be that command line matching is done using Sigar.
I may or may not develop a fix for this.
jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
---
Key: DAEMON-248
URL: https://issues.apache.org/jira/browse/DAEMON-248
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.0.2
Reporter: Elias Ross
Attachments: Test.java
Run a process using jsvc.exec
Then use the Attach API to locate the process.
Note that java.rt.vmArgs are not available. See the attached program.
monitoredhost = MonitoredHost.getMonitoredHost(new
HostIdentifier((String) null));
set = monitoredhost.activeVms();
... iterate
MonitoredVm monitoredvm =
monitoredhost.getMonitoredVm(new VmIdentifier(s));
ListMonitor l = monitoredvm.findByPattern(.*);
for (Monitor m : l) {
System.out.println( + m.getName() + +
m.getValue());
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-137) Main documentation page links wrong javadocs
[ https://issues.apache.org/jira/browse/CODEC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240755#comment-13240755 ] Karsten Tinnefeld commented on CODEC-137: - Ok, let's change the description to outdated javadoc should be replaced by proper stable current api and link properly labeled. Main documentation page links wrong javadocs Key: CODEC-137 URL: https://issues.apache.org/jira/browse/CODEC-137 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Chrome 18, but I guess any browser Reporter: Karsten Tinnefeld Priority: Minor Labels: documentation Original Estimate: 1h Remaining Estimate: 1h http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but in fact links 1.4 javadocs. Thus, some prominent new features are not properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-213) _numActive can go negative
[
https://issues.apache.org/jira/browse/POOL-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240805#comment-13240805
]
Mark Mindenhall commented on POOL-213:
--
I spoke too soon. The current 1.6 release (that can be downloaded) has exactly
the same problem with the invalidateObject method:
{code}
public void invalidateObject(T obj) throws Exception {
try {
if (_factory != null) {
_factory.destroyObject(obj);
}
} finally {
synchronized (this) {
_numActive--;
}
allocate();
}
}
{code}
When you suggested version 1.6, I looked at the version of GenericObjectPool in
trunk, which fixes the problem. What's the status of that release? It looks
like a major refactoring (even the package name has changed from
org.apache.commons.pool to org.apache.commons.pool2).
_numActive can go negative
--
Key: POOL-213
URL: https://issues.apache.org/jira/browse/POOL-213
Project: Commons Pool
Issue Type: Bug
Affects Versions: 1.5.4
Reporter: Mark Mindenhall
I'm working on a project that uses Hector (Cassandra client). Hector uses
commons-pool (we're using 1.5.4) to pool connections to hosts within a
Cassandra cluster. Hector provides a JMX MBean that exposes a NumActive
property, which is the cumulative call to retrieve numActive from all of the
individual connection pools. When querying this property via JMS on our
production servers, we often see negative values. For example, on a server
that has three connection pools, the NumActive property reported was -3899.
I know this issue has been reported before (POOL-29), and was supposedly
fixed. The fix discussed there was to merely check the value of _numActive
to prevent it from going negative. However, that does not fix the real
problem here, which is that it is possible to decrement _numActive more than
once for each activated object.
For example, from a quick look at the code (GenericObjectPool.java, v1.5.4),
it would be possible to do the following:
1) Create a pool with 10 objects.
2) Borrow all 10 objects from the pool.
3) Call getNumActive (returns 10).
4) Call invalidateObject for ONE of the objects 11 times.
5) Call getNumActive (returns -1).
The invalidateObject method calls the _factory to destroy the object, and
subsequent calls to destroy the same object may or may not result in an
exception. Regardless, _numActive is decremented within a finally block, and
therefore would always be decremented even if the object had already been
invalidated and destroyed.
I'd like to suggest using a HashSet instead of a counter to keep track of
active objects. If borrowing an object added it to a HashSet, and returning
or invaliding the object removed it from the HashSet (subsequent removes
would be no-ops), the example given above would not result in an incorrect
value when getNumActive is called (it would just return the current size of
the HashSet).
Note that although unrelated to this bug, it might also be wise to use a
HashSet instead of the int counter _numInternalProcessing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
