[jira] [Issue Comment Deleted] (COLLECTIONS-546) Implement expiring queue like already exist PassiveExpiringMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chen updated COLLECTIONS-546: - Comment: was deleted (was: Hello, [~Suryakanth], [~tn], Has this feature been implemented?) > Implement expiring queue like already exist PassiveExpiringMap > -- > > Key: COLLECTIONS-546 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-546 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Affects Versions: 4.x >Reporter: Guram Savinov >Priority: Major > Labels: collection, expiration, queue > > It's very useful collection wrapper for map with expiration - > PassiveExpiringMap. > Can you implement queue with expiration like already exist PassiveExpiringMap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-477) Support for splitted zip files
[
https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=343050&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-343050
]
ASF GitHub Bot logged work on COMPRESS-477:
---
Author: ASF GitHub Bot
Created on: 14/Nov/19 01:12
Start Date: 14/Nov/19 01:12
Worklog Time Spent: 10m
Work Description: PeterAlfreadLee commented on issue #84: COMPRESS-477
Add support for extracting splitted zip files
URL: https://github.com/apache/commons-compress/pull/84#issuecomment-553677838
Hi, @bodewig
How is this PR being reviewed by now? Please feel free to let me know any
kind of problems I need to modify.
I have already pushed the new PR about building a split zip. Unfortunely
there are some minor merge conflicts in the new PR with this PR(like
`getBaseName`, adding `diskNumberStart` in `ZipArchiveEntry` and some files for
testing), and some testcases need to be added to valid the building of split
zip(I can also import a new library to validate it, but I don't want to do
that). I hope this PR could be merged so that I can resolve these conflists,
but of course you can merge them and resoulve these problems by yourself. It's
all up to you.
Thank you for your effort creating such a great library.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 343050)
Time Spent: 3.5h (was: 3h 20m)
> Support for splitted zip files
> --
>
> Key: COMPRESS-477
> URL: https://issues.apache.org/jira/browse/COMPRESS-477
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Luís Filipe Nassif
>Priority: Major
> Labels: zip
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> It would be very useful to support splitted zip files. I've read
> [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood
> that simply concatenating the segments and removing the split signature
> 0x08074b50 from first segment would be sufficient, but it is not that simple
> because compress fails with exception below:
> {code}
> Caused by: java.util.zip.ZipException: archive's ZIP64 end of central
> directory locator is corrupt.
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236)
> ~[commons-compress-1.18.jar:1.18]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfreadLee commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files
PeterAlfreadLee commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files URL: https://github.com/apache/commons-compress/pull/84#issuecomment-553677838 Hi, @bodewig How is this PR being reviewed by now? Please feel free to let me know any kind of problems I need to modify. I have already pushed the new PR about building a split zip. Unfortunely there are some minor merge conflicts in the new PR with this PR(like `getBaseName`, adding `diskNumberStart` in `ZipArchiveEntry` and some files for testing), and some testcases need to be added to valid the building of split zip(I can also import a new library to validate it, but I don't want to do that). I hope this PR could be merged so that I can resolve these conflists, but of course you can merge them and resoulve these problems by yourself. It's all up to you. Thank you for your effort creating such a great library. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] aherbert commented on a change in pull request #27: Murmur3fix
aherbert commented on a change in pull request #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#discussion_r346078788
##
File path: src/test/java/org/apache/commons/codec/digest/MurmurHash3Test.java
##
@@ -224,4 +225,238 @@ public void testSingleLongRandom() {
}
}
+ @Test
+public void test32_x86_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final int result = MurmurHash3.hash32_x86(origin);
+
+// Assert
+assertEquals(-436507231, result);
+}
+
+@Test
+public void test128_x64_Short() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.SHORT_BYTES);
+BUFFER.putShort(0, (short) 2);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(8673501042631707204L, result[0]);
+assertEquals(491907755572407714L, result[1]);
+}
+
+@Test
+public void test128_x64_Int() {
+// Arrange
+final ByteBuffer BUFFER =
ByteBuffer.allocate(MurmurHash3.INTEGER_BYTES);
+BUFFER.putInt(0, 3);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2448828847287705405L, result[0]);
+assertEquals(-4568642211270719983L, result[1]);
+}
+
+@Test
+public void test128_x64_Long() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+BUFFER.putLong(0, 8675309L);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2339756411022791995L, result[0]);
+assertEquals(8242951144762217305L, result[1]);
+}
+
+@Test
+public void test128_x64_Double() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(Double.SIZE / Byte.SIZE);
+BUFFER.putDouble(0, 456.987);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6877430437712399133L, result[0]);
+assertEquals(-8576421050167250536L, result[1]);
+}
+
+@Test
+public void test128_x64_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(origin);
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6409160382500807310L, result[0]);
+assertEquals(-7835827609130513921L, result[1]);
+}
+
+
+
+@Test
+public void testTwoLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+buffer.putLong(0, i);
+buffer.putLong(MurmurHash3.LONG_BYTES, j);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i, j));
+}
+}
+}
+
+@Test
+public void testTwoLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+final long x = random.nextLong();
+final long y = random.nextLong();
+buffer.putLong(0, x);
+buffer.putLong(MurmurHash3.LONG_BYTES, y);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x, y));
+}
+}
+}
+
+@Test
+public void testSingleLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+for (long i = 0; i < 1000; i++) {
+buffer.putLong(0, i);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i));
+}
+}
+
+@Test
+public void testSingleLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+final long x = random.nextLong();
+buffer.putLong(0, x);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x));
+}
+}
+
+@Test
Review comment:
All code from this point down has different whitespace indentation.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For qu
[GitHub] [commons-codec] aherbert commented on a change in pull request #27: Murmur3fix
aherbert commented on a change in pull request #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#discussion_r346078161
##
File path: src/test/java/org/apache/commons/codec/digest/MurmurHash3Test.java
##
@@ -224,4 +225,238 @@ public void testSingleLongRandom() {
}
}
+ @Test
+public void test32_x86_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final int result = MurmurHash3.hash32_x86(origin);
+
+// Assert
+assertEquals(-436507231, result);
+}
+
+@Test
+public void test128_x64_Short() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.SHORT_BYTES);
+BUFFER.putShort(0, (short) 2);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(8673501042631707204L, result[0]);
+assertEquals(491907755572407714L, result[1]);
+}
+
+@Test
+public void test128_x64_Int() {
+// Arrange
+final ByteBuffer BUFFER =
ByteBuffer.allocate(MurmurHash3.INTEGER_BYTES);
+BUFFER.putInt(0, 3);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2448828847287705405L, result[0]);
+assertEquals(-4568642211270719983L, result[1]);
+}
+
+@Test
+public void test128_x64_Long() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+BUFFER.putLong(0, 8675309L);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2339756411022791995L, result[0]);
+assertEquals(8242951144762217305L, result[1]);
+}
+
+@Test
+public void test128_x64_Double() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(Double.SIZE / Byte.SIZE);
+BUFFER.putDouble(0, 456.987);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6877430437712399133L, result[0]);
+assertEquals(-8576421050167250536L, result[1]);
+}
+
+@Test
+public void test128_x64_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(origin);
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6409160382500807310L, result[0]);
+assertEquals(-7835827609130513921L, result[1]);
+}
+
+
+
+@Test
+public void testTwoLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+buffer.putLong(0, i);
+buffer.putLong(MurmurHash3.LONG_BYTES, j);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i, j));
+}
+}
+}
+
+@Test
+public void testTwoLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+final long x = random.nextLong();
+final long y = random.nextLong();
+buffer.putLong(0, x);
+buffer.putLong(MurmurHash3.LONG_BYTES, y);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x, y));
+}
+}
+}
+
+@Test
+public void testSingleLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+for (long i = 0; i < 1000; i++) {
+buffer.putLong(0, i);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i));
+}
+}
+
+@Test
+public void testSingleLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+final long x = random.nextLong();
+buffer.putLong(0, x);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x));
+}
+}
+
+@Test
+public void testCorrectValues() throws Exception {
+byte[] bytes = "Now is the time for all good men to come to the aid of
their country".getBytes("UTF-8");
+int hash=0;
+for (int i=0; i
[GitHub] [commons-codec] aherbert commented on a change in pull request #27: Murmur3fix
aherbert commented on a change in pull request #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#discussion_r346078610
##
File path: src/test/java/org/apache/commons/codec/digest/MurmurHash3Test.java
##
@@ -224,4 +225,238 @@ public void testSingleLongRandom() {
}
}
+ @Test
+public void test32_x86_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final int result = MurmurHash3.hash32_x86(origin);
+
+// Assert
+assertEquals(-436507231, result);
+}
+
+@Test
+public void test128_x64_Short() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.SHORT_BYTES);
+BUFFER.putShort(0, (short) 2);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(8673501042631707204L, result[0]);
+assertEquals(491907755572407714L, result[1]);
+}
+
+@Test
+public void test128_x64_Int() {
+// Arrange
+final ByteBuffer BUFFER =
ByteBuffer.allocate(MurmurHash3.INTEGER_BYTES);
+BUFFER.putInt(0, 3);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2448828847287705405L, result[0]);
+assertEquals(-4568642211270719983L, result[1]);
+}
+
+@Test
+public void test128_x64_Long() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+BUFFER.putLong(0, 8675309L);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2339756411022791995L, result[0]);
+assertEquals(8242951144762217305L, result[1]);
+}
+
+@Test
+public void test128_x64_Double() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(Double.SIZE / Byte.SIZE);
+BUFFER.putDouble(0, 456.987);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6877430437712399133L, result[0]);
+assertEquals(-8576421050167250536L, result[1]);
+}
+
+@Test
+public void test128_x64_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(origin);
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6409160382500807310L, result[0]);
+assertEquals(-7835827609130513921L, result[1]);
+}
+
+
+
+@Test
+public void testTwoLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+buffer.putLong(0, i);
+buffer.putLong(MurmurHash3.LONG_BYTES, j);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i, j));
+}
+}
+}
+
+@Test
+public void testTwoLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+final long x = random.nextLong();
+final long y = random.nextLong();
+buffer.putLong(0, x);
+buffer.putLong(MurmurHash3.LONG_BYTES, y);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x, y));
+}
+}
+}
+
+@Test
+public void testSingleLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+for (long i = 0; i < 1000; i++) {
+buffer.putLong(0, i);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i));
+}
+}
+
+@Test
+public void testSingleLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+final long x = random.nextLong();
+buffer.putLong(0, x);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x));
+}
+}
+
+@Test
+public void testCorrectValues() throws Exception {
+byte[] bytes = "Now is the time for all good men to come to the aid of
their country".getBytes("UTF-8");
+int hash=0;
+for (int i=0; i
[GitHub] [commons-codec] aherbert commented on a change in pull request #27: Murmur3fix
aherbert commented on a change in pull request #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#discussion_r346076407
##
File path: src/test/java/org/apache/commons/codec/digest/MurmurHash3Test.java
##
@@ -224,4 +225,238 @@ public void testSingleLongRandom() {
}
}
+ @Test
+public void test32_x86_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final int result = MurmurHash3.hash32_x86(origin);
+
+// Assert
+assertEquals(-436507231, result);
+}
+
+@Test
+public void test128_x64_Short() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.SHORT_BYTES);
+BUFFER.putShort(0, (short) 2);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(8673501042631707204L, result[0]);
+assertEquals(491907755572407714L, result[1]);
+}
+
+@Test
+public void test128_x64_Int() {
+// Arrange
+final ByteBuffer BUFFER =
ByteBuffer.allocate(MurmurHash3.INTEGER_BYTES);
+BUFFER.putInt(0, 3);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2448828847287705405L, result[0]);
+assertEquals(-4568642211270719983L, result[1]);
+}
+
+@Test
+public void test128_x64_Long() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+BUFFER.putLong(0, 8675309L);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(2339756411022791995L, result[0]);
+assertEquals(8242951144762217305L, result[1]);
+}
+
+@Test
+public void test128_x64_Double() {
+// Arrange
+final ByteBuffer BUFFER = ByteBuffer.allocate(Double.SIZE / Byte.SIZE);
+BUFFER.putDouble(0, 456.987);
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(BUFFER.array());
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6877430437712399133L, result[0]);
+assertEquals(-8576421050167250536L, result[1]);
+}
+
+@Test
+public void test128_x64_String() {
+// Arrange
+final String origin = TEST;
+
+// Act
+final long[] result = MurmurHash3.hash128_x64(origin);
+
+// Assert
+assertEquals(result.length, 2);
+assertEquals(6409160382500807310L, result[0]);
+assertEquals(-7835827609130513921L, result[1]);
+}
+
+
+
+@Test
+public void testTwoLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+buffer.putLong(0, i);
+buffer.putLong(MurmurHash3.LONG_BYTES, j);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i, j));
+}
+}
+}
+
+@Test
+public void testTwoLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES *
2);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+for (long j = 0; j < 1000; j++) {
+final long x = random.nextLong();
+final long y = random.nextLong();
+buffer.putLong(0, x);
+buffer.putLong(MurmurHash3.LONG_BYTES, y);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x, y));
+}
+}
+}
+
+@Test
+public void testSingleLongOrdered_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+for (long i = 0; i < 1000; i++) {
+buffer.putLong(0, i);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(i));
+}
+}
+
+@Test
+public void testSingleLongRandom_32x86() {
+final ByteBuffer buffer = ByteBuffer.allocate(MurmurHash3.LONG_BYTES);
+final Random random = new Random();
+for (long i = 0; i < 1000; i++) {
+final long x = random.nextLong();
+buffer.putLong(0, x);
+assertEquals(MurmurHash3.hash32_x86(buffer.array()),
MurmurHash3.hash32_x86(x));
+}
+}
+
+@Test
+public void testCorrectValues() throws Exception {
+byte[] bytes = "Now is the time for all good men to come to the aid of
their country".getBytes("UTF-8");
+int hash=0;
+for (int i=0; i
[GitHub] [commons-codec] Claudenw commented on issue #27: Murmur3fix
Claudenw commented on issue #27: Murmur3fix URL: https://github.com/apache/commons-codec/pull/27#issuecomment-553627225 Would someone please merge this? The two errors are in a file I did not touch and are in the base build. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] coveralls edited a comment on issue #27: Murmur3fix
coveralls edited a comment on issue #27: Murmur3fix URL: https://github.com/apache/commons-codec/pull/27#issuecomment-549122650 [](https://coveralls.io/builds/26972764) Coverage decreased (-0.06%) to 92.724% when pulling **ffa0c7faf3eecabadcfee79a74d7e94ba6b7d7d4 on Claudenw:murmur3fix** into **f0e122da19684394123c85577405d6dc7cddbb98 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-dbcp] louislatreille opened a new pull request #35: DBCP-558 Fix DelegatingConnection readOnly and autoCommit caching mechanism
louislatreille opened a new pull request #35: DBCP-558 Fix DelegatingConnection readOnly and autoCommit caching mechanism URL: https://github.com/apache/commons-dbcp/pull/35 https://issues.apache.org/jira/browse/DBCP-558 Previously, we would cache the input of setReadOnly and setAutoCommit directly without checking if the underlying connection succeeded in setting the configuration parameter. This would result in wrong results from isReadOnly and getAutoCommit if the underlying connection didn't support read-only/non-read-only or auto-commit/non-auto-commit connections, as with SqlServerConnection. This fixes the issue by caching what is return by isReadOnly and getAutoCommit from the underlying connection. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (DBCP-558) DelegatingConnection setReadOnly and setAutoCommit sometimes caches the wrong value
[ https://issues.apache.org/jira/browse/DBCP-558?focusedWorklogId=342722&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-342722 ] ASF GitHub Bot logged work on DBCP-558: --- Author: ASF GitHub Bot Created on: 13/Nov/19 17:03 Start Date: 13/Nov/19 17:03 Worklog Time Spent: 10m Work Description: louislatreille commented on pull request #35: DBCP-558 Fix DelegatingConnection readOnly and autoCommit caching mechanism URL: https://github.com/apache/commons-dbcp/pull/35 https://issues.apache.org/jira/browse/DBCP-558 Previously, we would cache the input of setReadOnly and setAutoCommit directly without checking if the underlying connection succeeded in setting the configuration parameter. This would result in wrong results from isReadOnly and getAutoCommit if the underlying connection didn't support read-only/non-read-only or auto-commit/non-auto-commit connections, as with SqlServerConnection. This fixes the issue by caching what is return by isReadOnly and getAutoCommit from the underlying connection. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 342722) Remaining Estimate: 0h Time Spent: 10m > DelegatingConnection setReadOnly and setAutoCommit sometimes caches the wrong > value > --- > > Key: DBCP-558 > URL: https://issues.apache.org/jira/browse/DBCP-558 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: Louis Latreille >Priority: Minor > Fix For: 2.7.1 > > Time Spent: 10m > Remaining Estimate: 0h > > DelegatingConnection caches the input of setReadOnly and setAutoCommit > directly without checking if the underlying connection succeeded in setting > the configuration parameter. This results in wrong return value from > isReadOnly and getAutoCommit if the underlying connection doesn't support > read-only/non-read-only or auto-commit/non-auto-commit connections, as with > SqlServerConnection. > > To reproduce the issue: > # Create a DelegatingConnection with an underlying SqlServerConnection > # Set the connection read-only `con.setReadOnly(true)` > # Query the read-only state on the DelegatingConnection, you will get true > # Query the read-only state of the underlying SqlServerConnection, you will > get false (SqlServer JDBC driver doesn't support read-only connections) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (DBCP-558) DelegatingConnection setReadOnly and setAutoCommit sometimes caches the wrong value
Louis Latreille created DBCP-558: Summary: DelegatingConnection setReadOnly and setAutoCommit sometimes caches the wrong value Key: DBCP-558 URL: https://issues.apache.org/jira/browse/DBCP-558 Project: Commons DBCP Issue Type: Bug Affects Versions: 2.2.0 Reporter: Louis Latreille Fix For: 2.7.1 DelegatingConnection caches the input of setReadOnly and setAutoCommit directly without checking if the underlying connection succeeded in setting the configuration parameter. This results in wrong return value from isReadOnly and getAutoCommit if the underlying connection doesn't support read-only/non-read-only or auto-commit/non-auto-commit connections, as with SqlServerConnection. To reproduce the issue: # Create a DelegatingConnection with an underlying SqlServerConnection # Set the connection read-only `con.setReadOnly(true)` # Query the read-only state on the DelegatingConnection, you will get true # Query the read-only state of the underlying SqlServerConnection, you will get false (SqlServer JDBC driver doesn't support read-only connections) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CONFIGURATION-769) commons configuration addProperty method replaces <
Deepraj jha created CONFIGURATION-769:
-
Summary: commons configuration addProperty method replaces < >
with < >
Key: CONFIGURATION-769
URL: https://issues.apache.org/jira/browse/CONFIGURATION-769
Project: Commons Configuration
Issue Type: Bug
Components: Format
Affects Versions: 2.6
Reporter: Deepraj jha
I am using latest Apache commons configuration 2 version 2.6 and when trying to
invoke addProperty it replaces < > with < >.
example :
cfg.addProperty("data.array(0).var(0)", "" );
cfg.write(new FileWriter(this.XmlFile));
Here cfg is XMLConfiguration Object
The resulting xml is :
{{}}
Expected is :
{{""}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DAEMON-412) Tomcat started as windows service does not support Java Native Memory Tracking feature probably because of improper JVM initialization by Procrun
[ https://issues.apache.org/jira/browse/DAEMON-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artur Linhart updated DAEMON-412: - Description: In the case the user specifies some from the the NativeMemoryTracking parameters (see [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] ) like -XX:NativeMemoryTracking=summary in Windows service registry, restarts the service, so the option can be seen in the log file by the startup options (for example in Tomcat logs like catalina.log), then the Native memory tracking is still disabled and does not work. If you try with jcmd VM.native_memory summary to get the information about the native JVM memory in the tomcats JVM, the jcmd call fails with the message : Native memory tracking is not enabled and in the Tomcat's log file can be found following error message: Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not setup properly, using wrong launcher? The problem seems to be in the JVM launcher Procrun, which dies not initialize the JVM properly - as far as I have understood from this blog: [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] The Procrun.exe has to define some environment variable before the start of JVM, etc. to get the native memory tracking to work. Known workaround is the start of Tomcat from the command line, but this is no option in the productive environment, where you have to let the service run for longer time to collect the proper result and maybe also as some different user because of security concerns, then such option is simply out of possible scenarios. So the Tomcat service JVM cannot be in such circumstances tracked by NMT at all, what is the problem in the mission-critical applications. The Procrun should be modified in the way it enables the NMT in the windows service by the startup, by setting the environment variable NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) in the dependency on the specified or unspecified option of -XX:NativeMemoryTracking like done normally by java.exe Remark: Also change of the startup mode from "jvm" to "exe" or "java" does not help,. then the windows service does not start at all. See also the Tomcat bug [https://bz.apache.org/bugzilla/show_bug.cgi?id=63922|https://bz.apache.org/bugzilla/show_bug.cgi?id=63922] which has been qualified as invalid because the problem seems to be in is in PROCRUN. See also the bug [TOMEE-2738] This will probably affect every java app handled by the Procrun Daemon, if installed and started as Windows service, not only Tomcat. was: In the case the user specifies some from the the NativeMemoryTracking parameters (see [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] ) like -XX:NativeMemoryTracking=summary in Windows service registry, restarts the service, so the option can be seen in the log file by the startup options, then the Native memory tracking is still disabled and does not work. If you try with jcmd VM.native_memory summary to get the information about the native JVM memory in the tomcats JVM, the jcmd call fails with the message : Native memory tracking is not enabled and in the Tomcat's log file can be found following error message: Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not setup properly, using wrong launcher? The problem seems to be in the JVM launcher Procrun, which dies not initialize the JVM properly - as far as I have understood from this blog: [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] The Procrun.exe has to define some environment variable before the start of JVM, etc. to get the native memory tracking to work. Known workaround is the start of Tomcat from the command line, but this is no option in the productive environment, where you have to let the service run for longer time to collect the proper result and maybe also as some different user because of security concerns, then such option is simply out of possible scenarios. So the Tomcat service JVM cannot be in such circumstances tracked by NMT at all, what is the problem in the mission-critical applications. The Procrun should be modified in the way it enables the NMT in the windows service by the startup, by setting the environment variable NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) in the dependency on the specifie
[jira] [Updated] (DAEMON-412) Tomcat started as windows service does not support Java Native Memory Tracking feature probably because of improper JVM initialization by Procrun
[ https://issues.apache.org/jira/browse/DAEMON-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artur Linhart updated DAEMON-412: - Environment: Windows generally (tested on Windows Server 2012 R2 but the problem occurs probably, like the user in the internet write, on every Windows version) (was: Windows) > Tomcat started as windows service does not support Java Native Memory > Tracking feature probably because of improper JVM initialization by Procrun > - > > Key: DAEMON-412 > URL: https://issues.apache.org/jira/browse/DAEMON-412 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun > Environment: Windows generally (tested on Windows Server 2012 R2 but > the problem occurs probably, like the user in the internet write, on every > Windows version) >Reporter: Artur Linhart >Priority: Major > > In the case the user specifies some from the the NativeMemoryTracking > parameters (see > [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 > > |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] > ) like > -XX:NativeMemoryTracking=summary > in Windows service registry, restarts the service, so the option can be seen > in the log file by the startup options, then the Native memory tracking is > still disabled and does not work. If you try with > jcmd VM.native_memory summary > to get the information about the native JVM memory in the tomcats JVM, the > jcmd call fails with the message > : > Native memory tracking is not enabled > and in the Tomcat's log file can be found following error message: > Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not > setup properly, using wrong launcher? > The problem seems to be in the JVM launcher Procrun, which dies not > initialize the JVM properly - as far as I have understood from this blog: > [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher > |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] > The Procrun.exe has to define some environment variable before the start of > JVM, etc. to get the native memory tracking to work. > Known workaround is the start of Tomcat from the command line, but this is no > option in the productive environment, where you have to let the service run > for longer time to collect the proper result and maybe also as some different > user because of security concerns, then such option is simply out of possible > scenarios. So the Tomcat service JVM cannot be in such circumstances tracked > by NMT at all, what is the problem in the mission-critical applications. > The Procrun should be modified in the way it enables the NMT in the windows > service by the startup, by setting the environment variable > NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) > in the dependency on the specified or unspecified option of > -XX:NativeMemoryTracking > like done normally by java.exe > Remark: Also change of the startup mode from "jvm" to "exe" or "java" does > not help,. then the windows service does not start at all. > See also the Tomcat bug > [https://bz.apache.org/bugzilla/show_bug.cgi?id=63922|https://bz.apache.org/bugzilla/show_bug.cgi?id=63922] > which has been qualified as invalid because the problem seems to be in is in > PROCRUN. > See also the bug [TOMEE-2738] > This will probably affect every java app handled by the Procrun Daemon, if > installed and started as Windows service, not only Tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-735) Concurrent CircularFifoQueue
[
https://issues.apache.org/jira/browse/COLLECTIONS-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973450#comment-16973450
]
David Mollitor commented on COLLECTIONS-735:
[~Guoping1]
> Concurrent CircularFifoQueue
>
>
> Key: COLLECTIONS-735
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-735
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Reporter: David Mollitor
>Priority: Major
>
> Create a {{CircularFifoQueue}} that is also a {{BlockingQueue}}.
> That is to say, if the queue is full, overwrite the oldest element. If the
> queue is empty, the reader blocks until a value becomes available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DAEMON-412) Tomcat started as windows service does not support Java Native Memory Tracking feature probably because of improper JVM initialization by Procrun
[ https://issues.apache.org/jira/browse/DAEMON-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artur Linhart updated DAEMON-412: - Summary: Tomcat started as windows service does not support Java Native Memory Tracking feature probably because of improper JVM initialization by Procrun (was: Tomcat started as windows service does not support Java Native Memory Tracking feature because of improper JVM initialization by Procrun) > Tomcat started as windows service does not support Java Native Memory > Tracking feature probably because of improper JVM initialization by Procrun > - > > Key: DAEMON-412 > URL: https://issues.apache.org/jira/browse/DAEMON-412 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun > Environment: Windows >Reporter: Artur Linhart >Priority: Major > > In the case the user specifies some from the the NativeMemoryTracking > parameters (see > [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 > > |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] > ) like > -XX:NativeMemoryTracking=summary > in Windows service registry, restarts the service, so the option can be seen > in the log file by the startup options, then the Native memory tracking is > still disabled and does not work. If you try with > jcmd VM.native_memory summary > to get the information about the native JVM memory in the tomcats JVM, the > jcmd call fails with the message > : > Native memory tracking is not enabled > and in the Tomcat's log file can be found following error message: > Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not > setup properly, using wrong launcher? > The problem seems to be in the JVM launcher Procrun, which dies not > initialize the JVM properly - as far as I have understood from this blog: > [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher > |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] > The Procrun.exe has to define some environment variable before the start of > JVM, etc. to get the native memory tracking to work. > Known workaround is the start of Tomcat from the command line, but this is no > option in the productive environment, where you have to let the service run > for longer time to collect the proper result and maybe also as some different > user because of security concerns, then such option is simply out of possible > scenarios. So the Tomcat service JVM cannot be in such circumstances tracked > by NMT at all, what is the problem in the mission-critical applications. > The Procrun should be modified in the way it enables the NMT in the windows > service by the startup, by setting the environment variable > NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) > in the dependency on the specified or unspecified option of > -XX:NativeMemoryTracking > like done normally by java.exe > Remark: Also change of the startup mode from "jvm" to "exe" or "java" does > not help,. then the windows service does not start at all. > See also the Tomcat bug > [https://bz.apache.org/bugzilla/show_bug.cgi?id=63922|https://bz.apache.org/bugzilla/show_bug.cgi?id=63922] > which has been qualified as invalid because the problem seems to be in is in > PROCRUN. > See also the bug [TOMEE-2738] > This will probably affect every java app handled by the Procrun Daemon, if > installed and started as Windows service, not only Tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (COLLECTIONS-735) Concurrent CircularFifoQueue
David Mollitor created COLLECTIONS-735:
--
Summary: Concurrent CircularFifoQueue
Key: COLLECTIONS-735
URL: https://issues.apache.org/jira/browse/COLLECTIONS-735
Project: Commons Collections
Issue Type: Improvement
Components: Collection
Reporter: David Mollitor
Create a {{CircularFifoQueue}} that is also a {{BlockingQueue}}.
That is to say, if the queue is full, overwrite the oldest element. If the
queue is empty, the reader blocks until a value becomes available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DAEMON-412) Tomcat started as windows service does not support Java Native Memory Tracking feature because of improper JVM initialization by Procrun
[ https://issues.apache.org/jira/browse/DAEMON-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artur Linhart updated DAEMON-412: - Description: In the case the user specifies some from the the NativeMemoryTracking parameters (see [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] ) like -XX:NativeMemoryTracking=summary in Windows service registry, restarts the service, so the option can be seen in the log file by the startup options, then the Native memory tracking is still disabled and does not work. If you try with jcmd VM.native_memory summary to get the information about the native JVM memory in the tomcats JVM, the jcmd call fails with the message : Native memory tracking is not enabled and in the Tomcat's log file can be found following error message: Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not setup properly, using wrong launcher? The problem seems to be in the JVM launcher Procrun, which dies not initialize the JVM properly - as far as I have understood from this blog: [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] The Procrun.exe has to define some environment variable before the start of JVM, etc. to get the native memory tracking to work. Known workaround is the start of Tomcat from the command line, but this is no option in the productive environment, where you have to let the service run for longer time to collect the proper result and maybe also as some different user because of security concerns, then such option is simply out of possible scenarios. So the Tomcat service JVM cannot be in such circumstances tracked by NMT at all, what is the problem in the mission-critical applications. The Procrun should be modified in the way it enables the NMT in the windows service by the startup, by setting the environment variable NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) in the dependency on the specified or unspecified option of -XX:NativeMemoryTracking like done normally by java.exe Remark: Also change of the startup mode from "jvm" to "exe" or "java" does not help,. then the windows service does not start at all. See also the Tomcat bug [https://bz.apache.org/bugzilla/show_bug.cgi?id=63922|https://bz.apache.org/bugzilla/show_bug.cgi?id=63922] which has been qualified as invalid because the problem seems to be in is in PROCRUN. See also the bug [TOMEE-2738] This will probably affect every java app handled by the Procrun Daemon, if installed and started as Windows service, not only Tomcat. was: In the case the user specifies some from the the NativeMemoryTracking parameters (see [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] ) like -XX:NativeMemoryTracking=summary in Windows service registry, restarts the service, so the option can be seen in the log file by the startup options, then the Native memory tracking is still disabled and does not work. If you try with jcmd VM.native_memory summary to get the information about the native JVM memory in the tomcats JVM, the jcmd call fails with the message : Native memory tracking is not enabled and in the Tomcat's log file can be found following error message: Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not setup properly, using wrong launcher? The problem seems to be in the JVM launcher Procrun, which dies not initialize the JVM properly - as far as I have understood from this blog: [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] The Procrun.exe has to define some environment variable before the start of JVM, etc. to get the native memory tracking to work. Known workaround is the start of Tomcat from the command line, but this is no option in the productive environment, where you have to let the service run for longer time to collect the proper result and maybe also as some different user because of security concerns, then such option is simply out of possible scenarios. So the Tomcat service JVM cannot be in such circumstances tracked by NMT at all, what is the problem in the mission-critical applications. The Procrun should be modified in the way it enables the NMT in the windows service by the startup, by setting the environment variable NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) in the dependency on the specified or unspecified option of -XX:NativeMemoryTrac
[jira] [Comment Edited] (COLLECTIONS-733) Thread-Safe Array Blocking Deque
[
https://issues.apache.org/jira/browse/COLLECTIONS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973445#comment-16973445
]
David Mollitor edited comment on COLLECTIONS-733 at 11/13/19 3:34 PM:
--
[~Guoping1] I'm not sure that's the best approach. This would require
double-blocking. Once at the wrapper level, to check capacity, and one at the
{{ArrayBlockingQueue}} level to access the underlying data structure.
I think it would be best to wrap an {{ArrayDeque}} with the appropriate locking
facilities.
was (Author: belugabehr):
[~Guoping1] I'm not sure that's the best approach. This would require
double-blocking. Once at the wrapper level, to check capacity, and one at the
{{ArrayBlockingQueue}} level to access the underlying data structure.
> Thread-Safe Array Blocking Deque
>
>
> Key: COLLECTIONS-733
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-733
> Project: Commons Collections
> Issue Type: New Feature
>Reporter: David Mollitor
>Priority: Major
>
> The JDK offers an
> [ArrayDeque|https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html]
> which is a resizable-array implementation of the
> [Deque|https://docs.oracle.com/javase/8/docs/api/java/util/Deque.html]
> interface.
> The JDK also offers an
> [ArrayBlockingQueue|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ArrayBlockingQueue.html]
> which is a bounded blocking queue backed by an array.
> What I have had the need for several times now is a resizable-array
> implementation of a bounded blocking queue. It should implement all the same
> methods as the {{ArrayBlockingQueue}} but it can grow as needed, like an
> {{ArrayDeque}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-733) Thread-Safe Array Blocking Deque
[
https://issues.apache.org/jira/browse/COLLECTIONS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973445#comment-16973445
]
David Mollitor commented on COLLECTIONS-733:
[~Guoping1] I'm not sure that's the best approach. This would require
double-blocking. Once at the wrapper level, to check capacity, and one at the
{{ArrayBlockingQueue}} level to access the underlying data structure.
> Thread-Safe Array Blocking Deque
>
>
> Key: COLLECTIONS-733
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-733
> Project: Commons Collections
> Issue Type: New Feature
>Reporter: David Mollitor
>Priority: Major
>
> The JDK offers an
> [ArrayDeque|https://docs.oracle.com/javase/8/docs/api/java/util/ArrayDeque.html]
> which is a resizable-array implementation of the
> [Deque|https://docs.oracle.com/javase/8/docs/api/java/util/Deque.html]
> interface.
> The JDK also offers an
> [ArrayBlockingQueue|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ArrayBlockingQueue.html]
> which is a bounded blocking queue backed by an array.
> What I have had the need for several times now is a resizable-array
> implementation of a bounded blocking queue. It should implement all the same
> methods as the {{ArrayBlockingQueue}} but it can grow as needed, like an
> {{ArrayDeque}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DAEMON-412) Tomcat started as windows service does not support Java Native Memory Tracking feature because of improper JVM initialization by Procrun
Artur Linhart created DAEMON-412: Summary: Tomcat started as windows service does not support Java Native Memory Tracking feature because of improper JVM initialization by Procrun Key: DAEMON-412 URL: https://issues.apache.org/jira/browse/DAEMON-412 Project: Commons Daemon Issue Type: Bug Components: Procrun Environment: Windows Reporter: Artur Linhart In the case the user specifies some from the the NativeMemoryTracking parameters (see [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] ) like -XX:NativeMemoryTracking=summary in Windows service registry, restarts the service, so the option can be seen in the log file by the startup options, then the Native memory tracking is still disabled and does not work. If you try with jcmd VM.native_memory summary to get the information about the native JVM memory in the tomcats JVM, the jcmd call fails with the message : Native memory tracking is not enabled and in the Tomcat's log file can be found following error message: Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not setup properly, using wrong launcher? The problem seems to be in the JVM launcher Procrun, which dies not initialize the JVM properly - as far as I have understood from this blog: [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] The Procrun.exe has to define some environment variable before the start of JVM, etc. to get the native memory tracking to work. Known workaround is the start of Tomcat from the command line, but this is no option in the productive environment, where you have to let the service run for longer time to collect the proper result and maybe also as some different user because of security concerns, then such option is simply out of possible scenarios. So the Tomcat service JVM cannot be in such circumstances tracked by NMT at all, what is the problem in the mission-critical applications. The Procrun should be modified in the way it enables the NMT in the windows service by the startup, by setting the environment variable NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) in the dependency on the specified or unspecified option of -XX:NativeMemoryTracking like done normally by java.exe Remark: Also change of the startup mode from "jvm" to "exe" or "java" does not help,. then the windows service does not start at all. See also the Tomcat bug [https://bz.apache.org/bugzilla/show_bug.cgi?id=63922|https://bz.apache.org/bugzilla/show_bug.cgi?id=63922] which has been qualified as invalid because the problem seems to be in is in PROCRUN. See also the bug [TOMEE-2738] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973127#comment-16973127
]
Dmitri Blinov commented on JEXL-307:
Regarding new commit and new {{Lexical}} class which extends {{Stript}}. We
have {{Closure}} class which also extends from {{Script}}. I haven't tested it,
but does it mean the {{Closure}} will not support lexical feature?
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
