[jira] [Commented] (GEODE-10108) Duplicate Ops During GII/Delta Updates
[ https://issues.apache.org/jira/browse/GEODE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511532#comment-17511532 ] ASF subversion and git services commented on GEODE-10108: - Commit dca393f9767407265014fe57041a227cf78dc90c in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dca393f ] GEODE-10108: Remove extra enum written in ReplaceByteArrayAtOffset (#7477) > Duplicate Ops During GII/Delta Updates > --- > > Key: GEODE-10108 > URL: https://issues.apache.org/jira/browse/GEODE-10108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > When Redis commands are ongoing and a server that was previously not hosting > a bucket becomes the host of the primary bucket for a key, there exists a > time window where that server is performing GII but also receiving delta > updates from the previous primary bucket. This can lead to the delta being > applied to a data structure that is already in the “correct” state, resulting > in the command being applied twice. This can result in duplicated appends, > increments/decrements, and in the case of LTRIP and RPOP especially, > IndexOutOfBoundsException on the member applying the delta, as the index to > which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
[
https://issues.apache.org/jira/browse/GEODE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10160:
---
Description:
Some List methods aren't overriden in SizeableByteArrayList which means that
the memoryOverhead doesn't get updated. add(int index, byte[] element),
clear(), and set(int index, byte[] newElement) all need to update the size and
don't.
This can be accomplished by adding overrides to SizeableByteArrayList:
{code:java}
@Override
public byte[] set(int index, byte[] newElement) {
byte[] replacedElement = super.set(index, newElement);
memberOverhead -= calculateByteArrayOverhead(replacedElement);
memberOverhead += calculateByteArrayOverhead(newElement);
return replacedElement;
}
@Override
public void add(int index, byte[] element) {
memberOverhead += calculateByteArrayOverhead(element);
super.add(index, element);
}
{code}
The test for set could look something like:
{code:java}
@Test
public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
SizeableByteArrayList list = new SizeableByteArrayList();
byte[] element = "element".getBytes(StandardCharsets.UTF_8);
list.addFirst(element);
long initialSize = list.getSizeInBytes();
assertThat(initialSize).isEqualTo(sizer.sizeof(list));
list.set(0, "some really big new element
name".getBytes(StandardCharsets.UTF_8));
assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
list.set(0, element);
assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
}
{code}
We need more tests than just this one. add(int, byte[]) needs to be tested as
well. Any method on SizeableByteArrayList that modify the data should have a
test that the memoryOverhead gets updated correctly.
Clear itself isn't a problem - just set the memberOverhead to 0 - but the issue
is that for the version of LTRIM in
[PR#7403|https://github.com/apache/geode/pull/7403], we clear a sublist of
SizeableByteArrayList. This means that the overridden clear method does not get
called and the LinkedList implementation of clear does not call any other
methods that we can override. There needs to be some new approach to LTRIM that
doesn't use sublists.
was:
Some List methods aren't overriden in SizeableByteArrayList which means that
the memoryOverhead doesn't get updated. add(int index, byte[] element),
clear(), and set(int index, byte[] newElement) all need to update the size and
don't.
This can be accomplished by adding overrides to SizeableByteArrayList:
{code:java}
@Override
public byte[] set(int index, byte[] newElement) {
byte[] replacedElement = super.set(index, newElement);
memberOverhead -= calculateByteArrayOverhead(replacedElement);
memberOverhead += calculateByteArrayOverhead(newElement);
return replacedElement;
}
@Override
public void add(int index, byte[] element) {
memberOverhead += calculateByteArrayOverhead(element);
super.add(index, element);
}
{code}
The test for set could look something like:
{code:java}
@Test
public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
SizeableByteArrayList list = new SizeableByteArrayList();
byte[] element = "element".getBytes(StandardCharsets.UTF_8);
list.addFirst(element);
long initialSize = list.getSizeInBytes();
assertThat(initialSize).isEqualTo(sizer.sizeof(list));
list.set(0, "some really big new element
name".getBytes(StandardCharsets.UTF_8));
assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
list.set(0, element);
assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
}
{code}
We need more tests than just this one. add(int, byte[]) needs to be tested as
well. Any method on SizeableByteArrayList that modify the data should have a
test that the memoryOverhead gets updated correctly.
Clear itself isn't a problem - just set the memberOverhead to 0 - but the issue
is that for the version of LTRIM in PR#7403:
https://github.com/apache/geode/pull/7403, we clear a sublist of
SizeableByteArrayList. This means that the overridden clear method does not get
called and the LinkedList implementation of clear does not call any other
methods that we can override. There needs to be some new approach to LTRIM that
doesn't use sublists.
> SizeableByteArrayList does not update the sizeInBytes for some non-overriden
> methods
>
>
> Key: GEODE-10160
> URL: https://issues.apache.org/jira/browse/GEODE-10160
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: blocks-1.15.0
>
> Some List methods aren't overriden in SizeableByteArrayList which means that
> the memoryOverhead doesn't get
[jira] [Updated] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
[
https://issues.apache.org/jira/browse/GEODE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10160:
---
Description:
Some List methods aren't overriden in SizeableByteArrayList which means that
the memoryOverhead doesn't get updated. add(int index, byte[] element),
clear(), and set(int index, byte[] newElement) all need to update the size and
don't.
This can be accomplished by adding overrides to SizeableByteArrayList:
{code:java}
@Override
public byte[] set(int index, byte[] newElement) {
byte[] replacedElement = super.set(index, newElement);
memberOverhead -= calculateByteArrayOverhead(replacedElement);
memberOverhead += calculateByteArrayOverhead(newElement);
return replacedElement;
}
@Override
public void add(int index, byte[] element) {
memberOverhead += calculateByteArrayOverhead(element);
super.add(index, element);
}
{code}
The test for set could look something like:
{code:java}
@Test
public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
SizeableByteArrayList list = new SizeableByteArrayList();
byte[] element = "element".getBytes(StandardCharsets.UTF_8);
list.addFirst(element);
long initialSize = list.getSizeInBytes();
assertThat(initialSize).isEqualTo(sizer.sizeof(list));
list.set(0, "some really big new element
name".getBytes(StandardCharsets.UTF_8));
assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
list.set(0, element);
assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
}
{code}
We need more tests than just this one. add(int, byte[]) needs to be tested as
well. Any method on SizeableByteArrayList that modify the data should have a
test that the memoryOverhead gets updated correctly.
Clear itself isn't a problem - just set the memberOverhead to 0 - but the issue
is that for the version of LTRIM in PR#7403:
https://github.com/apache/geode/pull/7403, we clear a sublist of
SizeableByteArrayList. This means that the overridden clear method does not get
called and the LinkedList implementation of clear does not call any other
methods that we can override. There needs to be some new approach to LTRIM that
doesn't use sublists.
was:
Some List methods aren't overriden in SizeableByteArrayList which means that
the memoryOverhead doesn't get updated. add(int index, byte[] element),
clear(), and set(int index, byte[] newElement) all need to update the size and
don't.
This can be accomplished by adding overrides to SizeableByteArrayList:
{code:java}
@Override
public byte[] set(int index, byte[] newElement) {
byte[] replacedElement = super.set(index, newElement);
memberOverhead -= calculateByteArrayOverhead(replacedElement);
memberOverhead += calculateByteArrayOverhead(newElement);
return replacedElement;
}
@Override
public void add(int index, byte[] element) {
memberOverhead += calculateByteArrayOverhead(element);
super.add(index, element);
}
{code}
The test for set could look something like:
{code:java}
@Test
public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
SizeableByteArrayList list = new SizeableByteArrayList();
byte[] element = "element".getBytes(StandardCharsets.UTF_8);
list.addFirst(element);
long initialSize = list.getSizeInBytes();
assertThat(initialSize).isEqualTo(sizer.sizeof(list));
list.set(0, "some really big new element
name".getBytes(StandardCharsets.UTF_8));
assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
list.set(0, element);
assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
}
{code}
We need more tests than just this one. add(int, byte[]) needs to be tested as
well. Any method on SizeableByteArrayList that modify the data should have a
test that the memoryOverhead gets updated correctly.
Clear itself isn't a problem - just set the memberOverhead to 0 - but the issue
is that for the version of LTRIM in
(PR#7403)[https://github.com/apache/geode/pull/7403], we clear a sublist of
SizeableByteArrayList. This means that the overridden clear method does not get
called and the LinkedList implementation of clear does not call any other
methods that we can override. There needs to be some new approach to LTRIM that
doesn't use sublists.
> SizeableByteArrayList does not update the sizeInBytes for some non-overriden
> methods
>
>
> Key: GEODE-10160
> URL: https://issues.apache.org/jira/browse/GEODE-10160
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: blocks-1.15.0
>
> Some List methods aren't overriden in SizeableByteArrayList which means that
> the memoryOverhead doesn't get
[jira] [Updated] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
[
https://issues.apache.org/jira/browse/GEODE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10160:
---
Description:
Some List methods aren't overriden in SizeableByteArrayList which means that
the memoryOverhead doesn't get updated. add(int index, byte[] element),
clear(), and set(int index, byte[] newElement) all need to update the size and
don't.
This can be accomplished by adding overrides to SizeableByteArrayList:
{code:java}
@Override
public byte[] set(int index, byte[] newElement) {
byte[] replacedElement = super.set(index, newElement);
memberOverhead -= calculateByteArrayOverhead(replacedElement);
memberOverhead += calculateByteArrayOverhead(newElement);
return replacedElement;
}
@Override
public void add(int index, byte[] element) {
memberOverhead += calculateByteArrayOverhead(element);
super.add(index, element);
}
{code}
The test for set could look something like:
{code:java}
@Test
public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
SizeableByteArrayList list = new SizeableByteArrayList();
byte[] element = "element".getBytes(StandardCharsets.UTF_8);
list.addFirst(element);
long initialSize = list.getSizeInBytes();
assertThat(initialSize).isEqualTo(sizer.sizeof(list));
list.set(0, "some really big new element
name".getBytes(StandardCharsets.UTF_8));
assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
list.set(0, element);
assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
}
{code}
We need more tests than just this one. add(int, byte[]) needs to be tested as
well. Any method on SizeableByteArrayList that modify the data should have a
test that the memoryOverhead gets updated correctly.
Clear itself isn't a problem - just set the memberOverhead to 0 - but the issue
is that for the version of LTRIM in
(PR#7403)[https://github.com/apache/geode/pull/7403], we clear a sublist of
SizeableByteArrayList. This means that the overridden clear method does not get
called and the LinkedList implementation of clear does not call any other
methods that we can override. There needs to be some new approach to LTRIM that
doesn't use sublists.
was:
Some List methods aren't overriden in SizeableByteArrayList which means that
the memoryOverhead doesn't get updated. add(int index, byte[] element),
clear(), and set(int index, byte[] newElement) all need to update the size and
don't.
This can be accomplished by adding overrides to SizeableByteArrayList:
{code:java}
@Override
public byte[] set(int index, byte[] newElement) {
byte[] replacedElement = super.set(index, newElement);
memberOverhead -= calculateByteArrayOverhead(replacedElement);
memberOverhead += calculateByteArrayOverhead(newElement);
return replacedElement;
}
@Override
public void add(int index, byte[] element) {
memberOverhead += calculateByteArrayOverhead(element);
super.add(index, element);
}
{code}
The test for set could look something like:
{code:java}
@Test
public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
SizeableByteArrayList list = new SizeableByteArrayList();
byte[] element = "element".getBytes(StandardCharsets.UTF_8);
list.addFirst(element);
long initialSize = list.getSizeInBytes();
assertThat(initialSize).isEqualTo(sizer.sizeof(list));
list.set(0, "some really big new element
name".getBytes(StandardCharsets.UTF_8));
assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
list.set(0, element);
assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
}
{code}
We need more tests than just this one. add(int, byte[]) needs to be tested as
well. Any method on SizeableByteArrayList that modify the data should have a
test that the memoryOverhead gets updated correctly.
Clear itself isn't a problem - just set the memberOverhead to 0 - but the issue
is that for the version of LTRIM in
[PR#7403](https://github.com/apache/geode/pull/7403), we clear a sublist of
SizeableByteArrayList. This means that the overridden clear method does not get
called and the LinkedList implementation of clear does not call any other
methods that we can override. There needs to be some new approach to LTRIM that
doesn't use sublists.
> SizeableByteArrayList does not update the sizeInBytes for some non-overriden
> methods
>
>
> Key: GEODE-10160
> URL: https://issues.apache.org/jira/browse/GEODE-10160
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: blocks-1.15.0
>
> Some List methods aren't overriden in SizeableByteArrayList which means that
> the memoryOverhead doesn't get
[jira] [Updated] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
[
https://issues.apache.org/jira/browse/GEODE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10160:
---
Labels: blocks-1.15.0 (was: blocks-1.15.0)
> SizeableByteArrayList does not update the sizeInBytes for some non-overriden
> methods
>
>
> Key: GEODE-10160
> URL: https://issues.apache.org/jira/browse/GEODE-10160
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: blocks-1.15.0
>
> Some List methods aren't overriden in SizeableByteArrayList which means that
> the memoryOverhead doesn't get updated. add(int index, byte[] element),
> clear(), and set(int index, byte[] newElement) all need to update the size
> and don't.
> This can be accomplished by adding overrides to SizeableByteArrayList:
> {code:java}
> @Override
> public byte[] set(int index, byte[] newElement) {
> byte[] replacedElement = super.set(index, newElement);
> memberOverhead -= calculateByteArrayOverhead(replacedElement);
> memberOverhead += calculateByteArrayOverhead(newElement);
> return replacedElement;
> }
> @Override
> public void add(int index, byte[] element) {
> memberOverhead += calculateByteArrayOverhead(element);
> super.add(index, element);
> }
> {code}
> The test for set could look something like:
> {code:java}
> @Test
> public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
> SizeableByteArrayList list = new SizeableByteArrayList();
> byte[] element = "element".getBytes(StandardCharsets.UTF_8);
> list.addFirst(element);
> long initialSize = list.getSizeInBytes();
> assertThat(initialSize).isEqualTo(sizer.sizeof(list));
> list.set(0, "some really big new element
> name".getBytes(StandardCharsets.UTF_8));
> assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
> list.set(0, element);
> assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
> }
> {code}
> We need more tests than just this one. add(int, byte[]) needs to be tested as
> well. Any method on SizeableByteArrayList that modify the data should have a
> test that the memoryOverhead gets updated correctly.
> Clear itself isn't a problem - just set the memberOverhead to 0 - but the
> issue is that for the version of LTRIM in
> [PR#7403](https://github.com/apache/geode/pull/7403), we clear a sublist of
> SizeableByteArrayList. This means that the overridden clear method does not
> get called and the LinkedList implementation of clear does not call any other
> methods that we can override. There needs to be some new approach to LTRIM
> that doesn't use sublists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
[
https://issues.apache.org/jira/browse/GEODE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales updated GEODE-10160:
---
Labels: blocks-1.15.0 (was: needsTriage)
> SizeableByteArrayList does not update the sizeInBytes for some non-overriden
> methods
>
>
> Key: GEODE-10160
> URL: https://issues.apache.org/jira/browse/GEODE-10160
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: blocks-1.15.0
>
> Some List methods aren't overriden in SizeableByteArrayList which means that
> the memoryOverhead doesn't get updated. add(int index, byte[] element),
> clear(), and set(int index, byte[] newElement) all need to update the size
> and don't.
> This can be accomplished by adding overrides to SizeableByteArrayList:
> {code:java}
> @Override
> public byte[] set(int index, byte[] newElement) {
> byte[] replacedElement = super.set(index, newElement);
> memberOverhead -= calculateByteArrayOverhead(replacedElement);
> memberOverhead += calculateByteArrayOverhead(newElement);
> return replacedElement;
> }
> @Override
> public void add(int index, byte[] element) {
> memberOverhead += calculateByteArrayOverhead(element);
> super.add(index, element);
> }
> {code}
> The test for set could look something like:
> {code:java}
> @Test
> public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
> SizeableByteArrayList list = new SizeableByteArrayList();
> byte[] element = "element".getBytes(StandardCharsets.UTF_8);
> list.addFirst(element);
> long initialSize = list.getSizeInBytes();
> assertThat(initialSize).isEqualTo(sizer.sizeof(list));
> list.set(0, "some really big new element
> name".getBytes(StandardCharsets.UTF_8));
> assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
> list.set(0, element);
> assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
> }
> {code}
> We need more tests than just this one. add(int, byte[]) needs to be tested as
> well. Any method on SizeableByteArrayList that modify the data should have a
> test that the memoryOverhead gets updated correctly.
> Clear itself isn't a problem - just set the memberOverhead to 0 - but the
> issue is that for the version of LTRIM in
> [PR#7403](https://github.com/apache/geode/pull/7403), we clear a sublist of
> SizeableByteArrayList. This means that the overridden clear method does not
> get called and the LinkedList implementation of clear does not call any other
> methods that we can override. There needs to be some new approach to LTRIM
> that doesn't use sublists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
Hale Bales created GEODE-10160:
--
Summary: SizeableByteArrayList does not update the sizeInBytes for
some non-overriden methods
Key: GEODE-10160
URL: https://issues.apache.org/jira/browse/GEODE-10160
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Hale Bales
Some List methods aren't overriden in SizeableByteArrayList which means that
the memoryOverhead doesn't get updated. add(int index, byte[] element),
clear(), and set(int index, byte[] newElement) all need to update the size and
don't.
This can be accomplished by adding overrides to SizeableByteArrayList:
{code:java}
@Override
public byte[] set(int index, byte[] newElement) {
byte[] replacedElement = super.set(index, newElement);
memberOverhead -= calculateByteArrayOverhead(replacedElement);
memberOverhead += calculateByteArrayOverhead(newElement);
return replacedElement;
}
@Override
public void add(int index, byte[] element) {
memberOverhead += calculateByteArrayOverhead(element);
super.add(index, element);
}
{code}
The test for set could look something like:
{code:java}
@Test
public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
SizeableByteArrayList list = new SizeableByteArrayList();
byte[] element = "element".getBytes(StandardCharsets.UTF_8);
list.addFirst(element);
long initialSize = list.getSizeInBytes();
assertThat(initialSize).isEqualTo(sizer.sizeof(list));
list.set(0, "some really big new element
name".getBytes(StandardCharsets.UTF_8));
assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
list.set(0, element);
assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
}
{code}
We need more tests than just this one. add(int, byte[]) needs to be tested as
well. Any method on SizeableByteArrayList that modify the data should have a
test that the memoryOverhead gets updated correctly.
Clear itself isn't a problem - just set the memberOverhead to 0 - but the issue
is that for the version of LTRIM in
[PR#7403](https://github.com/apache/geode/pull/7403), we clear a sublist of
SizeableByteArrayList. This means that the overridden clear method does not get
called and the LinkedList implementation of clear does not call any other
methods that we can override. There needs to be some new approach to LTRIM that
doesn't use sublists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10160) SizeableByteArrayList does not update the sizeInBytes for some non-overriden methods
[
https://issues.apache.org/jira/browse/GEODE-10160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10160:
--
Labels: needsTriage (was: )
> SizeableByteArrayList does not update the sizeInBytes for some non-overriden
> methods
>
>
> Key: GEODE-10160
> URL: https://issues.apache.org/jira/browse/GEODE-10160
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> Some List methods aren't overriden in SizeableByteArrayList which means that
> the memoryOverhead doesn't get updated. add(int index, byte[] element),
> clear(), and set(int index, byte[] newElement) all need to update the size
> and don't.
> This can be accomplished by adding overrides to SizeableByteArrayList:
> {code:java}
> @Override
> public byte[] set(int index, byte[] newElement) {
> byte[] replacedElement = super.set(index, newElement);
> memberOverhead -= calculateByteArrayOverhead(replacedElement);
> memberOverhead += calculateByteArrayOverhead(newElement);
> return replacedElement;
> }
> @Override
> public void add(int index, byte[] element) {
> memberOverhead += calculateByteArrayOverhead(element);
> super.add(index, element);
> }
> {code}
> The test for set could look something like:
> {code:java}
> @Test
> public void sizeInBytesGetsUpdatedAccurately_whenDoingSets() {
> SizeableByteArrayList list = new SizeableByteArrayList();
> byte[] element = "element".getBytes(StandardCharsets.UTF_8);
> list.addFirst(element);
> long initialSize = list.getSizeInBytes();
> assertThat(initialSize).isEqualTo(sizer.sizeof(list));
> list.set(0, "some really big new element
> name".getBytes(StandardCharsets.UTF_8));
> assertThat(list.getSizeInBytes()).isEqualTo(sizer.sizeof(list));
> list.set(0, element);
> assertThat(list.getSizeInBytes()).isEqualTo(initialSize);
> }
> {code}
> We need more tests than just this one. add(int, byte[]) needs to be tested as
> well. Any method on SizeableByteArrayList that modify the data should have a
> test that the memoryOverhead gets updated correctly.
> Clear itself isn't a problem - just set the memberOverhead to 0 - but the
> issue is that for the version of LTRIM in
> [PR#7403](https://github.com/apache/geode/pull/7403), we clear a sublist of
> SizeableByteArrayList. This means that the overridden clear method does not
> get called and the LinkedList implementation of clear does not call any other
> methods that we can override. There needs to be some new approach to LTRIM
> that doesn't use sublists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511525#comment-17511525
]
Udo Kohlmeyer commented on GEODE-10045:
---
relates to https://issues.apache.org/jira/browse/GEODE-10159
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Issue Type: Improvement (was: Bug)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Labels: Micrometer (was: Micrometer blocks-1.15.0)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Parent: (was: GEODE-10003)
Issue Type: Bug (was: Sub-task)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer, blocks-1.15.0
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10159) Upgrade to Micrometer 1.9
Udo Kohlmeyer created GEODE-10159: - Summary: Upgrade to Micrometer 1.9 Key: GEODE-10159 URL: https://issues.apache.org/jira/browse/GEODE-10159 Project: Geode Issue Type: Sub-task Components: statistics Reporter: Udo Kohlmeyer Micrometer 2.x introduces a new set of issues: * Not being released in time for 9.15 * Package name restructuring * External public API's directly exposing the Micrometer classes, need to be updated, and in so any external projects depending the exposed API In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, Micrometer is releasing 1.9 version that will be the bridge between 1.x and 2.x. Spring Data Geode has already tested that updating to this version resolves the issues that it has when integrating with Spring Boot 3.0, and deems this version to be good. Micrometer 1.9 has not made GA yet, but it is expected to be released around May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10079) CI scripts no longer supply docker images for pre-1.15 PR precheck tasks
[ https://issues.apache.org/jira/browse/GEODE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10079: --- Labels: pull-request-available (was: ) > CI scripts no longer supply docker images for pre-1.15 PR precheck tasks > > > Key: GEODE-10079 > URL: https://issues.apache.org/jira/browse/GEODE-10079 > Project: Geode > Issue Type: Test > Components: ci >Affects Versions: 1.12.9, 1.13.8, 1.14.4 >Reporter: Dale Emery >Priority: Major > Labels: pull-request-available > > The CI scripts no longer supply docker images when they run PR precheck tasks > that use the `-PdunitDockerImage` property. > For PRs with base branches prior to `support/1.15`, the `distributedTest` and > `upgradeTest` precheck tasks must run each test class in a separate docker > container. When `dunitDockerImage` is not defined, these tasks instead run > tests concurrently outside of docker. This results in swarms of failures, as > the concurrently executing tests all attempt to bind to the same ports. > Examples: > - https://concourse.apachegeode-ci.info/builds/27926695 > - https://concourse.apachegeode-ci.info/builds/27632643 > - https://concourse.apachegeode-ci.info/builds/28861132 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10145) CI alpine tools image is compatibility issue
[ https://issues.apache.org/jira/browse/GEODE-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-10145. - Fix Version/s: 1.12.10 1.13.9 1.14.5 1.15.0 Resolution: Fixed > CI alpine tools image is compatibility issue > > > Key: GEODE-10145 > URL: https://issues.apache.org/jira/browse/GEODE-10145 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > Compatibility problem between alpine, cloud-sdk (google) and winrm-cli. > Re-organize the layers in the Dockerfile to straighten this out. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10133) ReflectionSingleObjectSizer throws when sizing hidden classes
[
https://issues.apache.org/jira/browse/GEODE-10133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10133:
---
Labels: Java17 pull-request-available (was: Java17)
> ReflectionSingleObjectSizer throws when sizing hidden classes
> -
>
> Key: GEODE-10133
> URL: https://issues.apache.org/jira/browse/GEODE-10133
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
>
> On JDK 17, the class of a lambda is a "hidden" class. When
> {{ReflectionSingleObjectSizer}} tries to find the offset of the fields of a
> hidden class, the JDK throws {{UnsupportedOperationException}}.
> Tests that fail due to this exception:
> - {{MemoryOverheadIntegrationTest}}
> - {{OutOfMemoryDUnitTest}}
> - {{SessionReplicationLocalCacheJUnitTest}}
> Example exception from {{MemoryOverheadIntegrationTest}}:
> {noformat}
> ava.lang.UnsupportedOperationException: can't get field offset on a hidden
> class: private final org.apache.geode.internal.cache.InternalCache
> org.apache.geode.redis.internal.GeodeRedisServer$$Lambda$607/0x0008011434d8.arg$1
> at sun.misc.Unsafe.objectFieldOffset(Unsafe.java:645)
> at
> org.apache.geode.unsafe.internal.sun.misc.Unsafe.fieldOffset(Unsafe.java:187)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:106)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:84)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:52)
> at
> org.apache.geode.internal.size.CachingSingleObjectSizer.sizeof(CachingSingleObjectSizer.java:39)
> at
> org.apache.geode.internal.size.ObjectGraphSizer$SizeVisitor.visit(ObjectGraphSizer.java:223)
> at
> org.apache.geode.internal.size.ObjectTraverser$VisitStack.add(ObjectTraverser.java:163)
> at
> org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:87)
> at
> org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
> at
> org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:96)
> at
> org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
[jira] [Commented] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511520#comment-17511520 ] Barrett Oglesby commented on GEODE-10148: - The test is saying that the result of this call to the locator is missing the CacheServer MBean that exists in the expectedMBeans list. List intermediateMBeans = getFederatedGemfireBeansFrom(locator1); That mbean list in the locator is updated asynchronously by the ManagementTask in each member. See ManagementResourceRepo.putAllInLocalMonitoringRegion. The localMonitoringRegion is DISTRIBUTED_NO_ACK. > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-10148: Assignee: Owen Nichols > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Assignee: Owen Nichols >Priority: Major > Labels: needsTriage > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10133) ReflectionSingleObjectSizer throws when sizing hidden classes
[
https://issues.apache.org/jira/browse/GEODE-10133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10133:
Assignee: Darrel Schneider
> ReflectionSingleObjectSizer throws when sizing hidden classes
> -
>
> Key: GEODE-10133
> URL: https://issues.apache.org/jira/browse/GEODE-10133
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> On JDK 17, the class of a lambda is a "hidden" class. When
> {{ReflectionSingleObjectSizer}} tries to find the offset of the fields of a
> hidden class, the JDK throws {{UnsupportedOperationException}}.
> Tests that fail due to this exception:
> - {{MemoryOverheadIntegrationTest}}
> - {{OutOfMemoryDUnitTest}}
> - {{SessionReplicationLocalCacheJUnitTest}}
> Example exception from {{MemoryOverheadIntegrationTest}}:
> {noformat}
> ava.lang.UnsupportedOperationException: can't get field offset on a hidden
> class: private final org.apache.geode.internal.cache.InternalCache
> org.apache.geode.redis.internal.GeodeRedisServer$$Lambda$607/0x0008011434d8.arg$1
> at sun.misc.Unsafe.objectFieldOffset(Unsafe.java:645)
> at
> org.apache.geode.unsafe.internal.sun.misc.Unsafe.fieldOffset(Unsafe.java:187)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:106)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:84)
> at
> org.apache.geode.internal.size.ReflectionSingleObjectSizer.sizeof(ReflectionSingleObjectSizer.java:52)
> at
> org.apache.geode.internal.size.CachingSingleObjectSizer.sizeof(CachingSingleObjectSizer.java:39)
> at
> org.apache.geode.internal.size.ObjectGraphSizer$SizeVisitor.visit(ObjectGraphSizer.java:223)
> at
> org.apache.geode.internal.size.ObjectTraverser$VisitStack.add(ObjectTraverser.java:163)
> at
> org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:87)
> at
> org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
> at
> org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:96)
> at
> org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
>
[jira] [Assigned] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrett Oglesby reassigned GEODE-10148: --- Assignee: (was: Barrett Oglesby) > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10158) offheap can incorrectly disable or enable the query monitor
[ https://issues.apache.org/jira/browse/GEODE-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10158: --- Labels: needsTriage pull-request-available (was: needsTriage) > offheap can incorrectly disable or enable the query monitor > > > Key: GEODE-10158 > URL: https://issues.apache.org/jira/browse/GEODE-10158 > Project: Geode > Issue Type: Bug > Components: offheap, querying >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: needsTriage, pull-request-available > > Geode has a QueryMonitor that should be disabled if the resource manager's > critical-heap-threshold is 0 and enabled if it is > 0. > But critical-offheap-threshold tries to also disable and enable the > QueryMonitor. I think this is wrong since queries do not consume off-heap > memory. QueryMonitor's relationship with the ResourceManager should only care > about the critical-heap-threshold. The biggest risk is that this bug could > cause the QueryMonitor to be disabled even though critical-heap-threshold is > > 0. This would allow queries to consume heap memory when instead they should > have failed with a LowMemoryException. > To workaround this issue make sure that if you are using offheap that you > either leave both critical thresholds set to 0 or set both of them to a > non-zero value. > A simple fix for this exists. Delete this one line from OffHeapMemoryMonitor: > cache.setQueryMonitorRequiredForResourceManager(criticalThreshold != 0); > A better fix would be to remove the > InternalCache.setQueryMonitorRequiredForResourceManager method and instead > have GemFireCacheImpl.getQueryMonitor method ask it's InternalResourceManager > if it requires a QueryMonitor. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511514#comment-17511514
]
ASF subversion and git services commented on GEODE-10127:
-
Commit c17509653d807026040121bcd63461de0eeba86c in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c175096 ]
GEODE-10127: Use correct hostname in WAN with LB test
This test is making gateway sender side members to connect to the receiver side
through a load balance. This test used "localhost" as the hostname for
clients. That worked previously, because we were actually losing the
hostname-for-clients in the RemoteLocatorResponse, and instead sending the IP
address, due to the changes in GEODE-8955.
With the fix for GEODE-10127, we are now correctly sending the
hostname-for-clients to the gateway sender, and so
now "localhost" doesn't work. The correct hostname-for-clients is the IP
address we get from docker-compose.
Changing the test to pass the IP address instead of "localhost" to the receiver
locator, just like we do for the receivers themselves.
Replacing the gfsh scripts in the
SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest with inline gfsh
-e statements in the java code.
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8955) WAN location service uses DistributedLocatorId.toString() to represent a locator
[
https://issues.apache.org/jira/browse/GEODE-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511515#comment-17511515
]
ASF subversion and git services commented on GEODE-8955:
Commit c17509653d807026040121bcd63461de0eeba86c in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c175096 ]
GEODE-10127: Use correct hostname in WAN with LB test
This test is making gateway sender side members to connect to the receiver side
through a load balance. This test used "localhost" as the hostname for
clients. That worked previously, because we were actually losing the
hostname-for-clients in the RemoteLocatorResponse, and instead sending the IP
address, due to the changes in GEODE-8955.
With the fix for GEODE-10127, we are now correctly sending the
hostname-for-clients to the gateway sender, and so
now "localhost" doesn't work. The correct hostname-for-clients is the IP
address we get from docker-compose.
Changing the test to pass the IP address instead of "localhost" to the receiver
locator, just like we do for the receivers themselves.
Replacing the gfsh scripts in the
SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest with inline gfsh
-e statements in the java code.
> WAN location service uses DistributedLocatorId.toString() to represent a
> locator
>
>
> Key: GEODE-8955
> URL: https://issues.apache.org/jira/browse/GEODE-8955
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Kevo
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> This code in LocatorHelper, and probably code in other parts of the WAN
> location service, uses DistributionLocatorId.toString() to track whether
> other locators have the WAN location service available. It should use the
> DistributionLocatorId.marshal() method instead. We should never use the
> toString() representation of an object in this way as it may change over time.
>
> {code:java}
> private static void addServerLocator(Integer distributedSystemId,
> LocatorMembershipListener locatorListener, DistributionLocatorId locator)
> {
> ConcurrentHashMap> allServerLocatorsInfo =
> (ConcurrentHashMap>)
> locatorListener.getAllServerLocatorsInfo();
> Set locatorsSet = new CopyOnWriteHashSet();
> locatorsSet.add(locator.toString());
> Set existingValue =
> allServerLocatorsInfo.putIfAbsent(distributedSystemId, locatorsSet);
> if (existingValue != null) {
> if (!existingValue.contains(locator.toString())) {
> existingValue.add(locator.toString());
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10158) offheap can incorrectly disable or enable the query monitor
[ https://issues.apache.org/jira/browse/GEODE-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-10158: Assignee: Darrel Schneider > offheap can incorrectly disable or enable the query monitor > > > Key: GEODE-10158 > URL: https://issues.apache.org/jira/browse/GEODE-10158 > Project: Geode > Issue Type: Bug > Components: offheap, querying >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: needsTriage > > Geode has a QueryMonitor that should be disabled if the resource manager's > critical-heap-threshold is 0 and enabled if it is > 0. > But critical-offheap-threshold tries to also disable and enable the > QueryMonitor. I think this is wrong since queries do not consume off-heap > memory. QueryMonitor's relationship with the ResourceManager should only care > about the critical-heap-threshold. The biggest risk is that this bug could > cause the QueryMonitor to be disabled even though critical-heap-threshold is > > 0. This would allow queries to consume heap memory when instead they should > have failed with a LowMemoryException. > To workaround this issue make sure that if you are using offheap that you > either leave both critical thresholds set to 0 or set both of them to a > non-zero value. > A simple fix for this exists. Delete this one line from OffHeapMemoryMonitor: > cache.setQueryMonitorRequiredForResourceManager(criticalThreshold != 0); > A better fix would be to remove the > InternalCache.setQueryMonitorRequiredForResourceManager method and instead > have GemFireCacheImpl.getQueryMonitor method ask it's InternalResourceManager > if it requires a QueryMonitor. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10145) CI alpine tools image is compatibility issue
[ https://issues.apache.org/jira/browse/GEODE-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511508#comment-17511508 ] ASF subversion and git services commented on GEODE-10145: - Commit 1d45268b05fa5ad6bcd70499c0125ce86562fc91 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1d45268 ] GEODE-10145: Java tools (such as javac) need to stay on the PATH (#7482) they were accidentally removed by prior PR#7466 for GEODE-10145 (cherry picked from commit 817860c649844484c39831873bb2e71ca978c08b) > CI alpine tools image is compatibility issue > > > Key: GEODE-10145 > URL: https://issues.apache.org/jira/browse/GEODE-10145 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Compatibility problem between alpine, cloud-sdk (google) and winrm-cli. > Re-organize the layers in the Dockerfile to straighten this out. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10145) CI alpine tools image is compatibility issue
[ https://issues.apache.org/jira/browse/GEODE-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511507#comment-17511507 ] ASF subversion and git services commented on GEODE-10145: - Commit f0d4dc65f4c91410777bac9eaee86f365c242c6d in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0d4dc6 ] GEODE-10145: Java tools (such as javac) need to stay on the PATH (#7482) they were accidentally removed by prior PR#7466 for GEODE-10145 (cherry picked from commit 817860c649844484c39831873bb2e71ca978c08b) > CI alpine tools image is compatibility issue > > > Key: GEODE-10145 > URL: https://issues.apache.org/jira/browse/GEODE-10145 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Compatibility problem between alpine, cloud-sdk (google) and winrm-cli. > Re-organize the layers in the Dockerfile to straighten this out. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10145) CI alpine tools image is compatibility issue
[ https://issues.apache.org/jira/browse/GEODE-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511506#comment-17511506 ] ASF subversion and git services commented on GEODE-10145: - Commit 2a1032d294b35635189d6cd115e84bc04a782ab4 in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2a1032d ] GEODE-10145: Java tools (such as javac) need to stay on the PATH (#7482) they were accidentally removed by prior PR#7466 for GEODE-10145 (cherry picked from commit 817860c649844484c39831873bb2e71ca978c08b) > CI alpine tools image is compatibility issue > > > Key: GEODE-10145 > URL: https://issues.apache.org/jira/browse/GEODE-10145 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Compatibility problem between alpine, cloud-sdk (google) and winrm-cli. > Re-organize the layers in the Dockerfile to straighten this out. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10145) CI alpine tools image is compatibility issue
[ https://issues.apache.org/jira/browse/GEODE-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511502#comment-17511502 ] ASF subversion and git services commented on GEODE-10145: - Commit 817860c649844484c39831873bb2e71ca978c08b in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=817860c ] GEODE-10145: Java tools (such as javac) need to stay on the PATH (#7482) they were accidentally removed by prior PR#7466 for GEODE-10145 > CI alpine tools image is compatibility issue > > > Key: GEODE-10145 > URL: https://issues.apache.org/jira/browse/GEODE-10145 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Compatibility problem between alpine, cloud-sdk (google) and winrm-cli. > Re-organize the layers in the Dockerfile to straighten this out. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-5564) Flaky test ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClear
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511501#comment-17511501
]
Geode Integration commented on GEODE-5564:
--
Seen on support/1.14 in [distributed-test-openjdk8
#37|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/distributed-test-openjdk8/builds/37]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/distributedTest/1648069661/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648069661/distributedtestfiles-openjdk8-1.14.5-build.0938.tgz].
> Flaky test ConcurrentIndexInitOnOverflowRegionDUnitTest >
> testIndexUpdateWithRegionClear
>
>
> Key: GEODE-5564
> URL: https://issues.apache.org/jira/browse/GEODE-5564
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0, 1.14.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> > testIndexUpdateWithRegionClear FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
> in VM 0 running on Host 92f89c21d1b0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
> Caused by:
> java.lang.AssertionError: After clear region size is supposed to be
> zero as all index updates are blocked. Current region size is: 13
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/556
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/547
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-5564) Flaky test ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClear
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-5564:
---
Affects Version/s: 1.14.0
> Flaky test ConcurrentIndexInitOnOverflowRegionDUnitTest >
> testIndexUpdateWithRegionClear
>
>
> Key: GEODE-5564
> URL: https://issues.apache.org/jira/browse/GEODE-5564
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0, 1.14.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> > testIndexUpdateWithRegionClear FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
> in VM 0 running on Host 92f89c21d1b0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
> Caused by:
> java.lang.AssertionError: After clear region size is supposed to be
> zero as all index updates are blocked. Current region size is: 13
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/556
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/547
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511500#comment-17511500 ] Geode Integration commented on GEODE-7739: -- Seen on support/1.13 in [distributed-test-openjdk11 #34|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/34] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0665/test-results/distributedTest/1648068571/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0665/test-artifacts/1648068571/distributedtestfiles-openjdk11-1.13.9-build.0665.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-4263) CI Failure: ResourceManagerWithQueryMonitorDUnitTest. testRM* are failing
[
https://issues.apache.org/jira/browse/GEODE-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511499#comment-17511499
]
Geode Integration commented on GEODE-4263:
--
Seen on support/1.12 in [distributed-test-openjdk11
#46|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk11/builds/46]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0362/test-results/distributedTest/1648069049/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0362/test-artifacts/1648069049/distributedtestfiles-openjdk11-1.12.10-build.0362.tgz].
> CI Failure: ResourceManagerWithQueryMonitorDUnitTest. testRM* are failing
> -
>
> Key: GEODE-4263
> URL: https://issues.apache.org/jira/browse/GEODE-4263
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.12.0
>Reporter: Nabarun Nag
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
>
> {noformat}
> java.lang.AssertionError: queryExecution.getResult() threw Exception
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doTestCriticalHeapAndQueryTimeout(ResourceManagerWithQueryMonitorDUnitTest.java:738)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.doCriticalMemoryHitTest(ResourceManagerWithQueryMonitorDUnitTest.java:321)
> at
> org.apache.geode.cache.query.dunit.ResourceManagerWithQueryMonitorDUnitTest.testRMAndTimeoutSet(ResourceManagerWithQueryMonitorDUnitTest.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
>
[jira] [Commented] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
[ https://issues.apache.org/jira/browse/GEODE-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511496#comment-17511496 ] Geode Integration commented on GEODE-7098: -- Seen on support/1.12 in [distributed-test-openjdk8 #47|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk8/builds/47] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0362/test-results/distributedTest/1648069451/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0362/test-artifacts/1648069451/distributedtestfiles-openjdk8-1.12.10-build.0362.tgz]. > Tomcat8SessionsClientServerDUnitTest fails with ConnectException > > > Key: GEODE-7098 > URL: https://issues.apache.org/jira/browse/GEODE-7098 > Project: Geode > Issue Type: Bug >Affects Versions: 1.11.0 >Reporter: Benjamin P Ross >Assignee: Mark Hanson >Priority: Major > Labels: flaky > Fix For: 1.13.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated > fail with > a ConnectException > org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > > testExtraSessionsNotCreated FAILED > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) > This could be an environmental error, but if a pattern develops it could be > due to a flaky test. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511495#comment-17511495
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-with-ssl
#223|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-ssl/builds/223].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-7960) CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion FAILED on Windows
[
https://issues.apache.org/jira/browse/GEODE-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511466#comment-17511466
]
Geode Integration commented on GEODE-7960:
--
Seen on support/1.14 in [windows-unit-test-openjdk8
#36|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/windows-unit-test-openjdk8/builds/36]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/test/1648064088/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648064088/windows-unittestfiles-openjdk8-1.14.5-build.0938.tgz].
> CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion
> FAILED on Windows
>
>
> Key: GEODE-7960
> URL: https://issues.apache.org/jira/browse/GEODE-7960
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>Priority: Major
>
> Looks like a flaky test on windows:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/21
> {noformat}
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest
> > logsMissingChildRegionUntilCompletion FAILED
> org.mockito.exceptions.verification.NoInteractionsWanted:
> No interactions wanted here:
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180)
> But found this interaction on mock 'consumer':
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> ***
> For your reference, here is the list of all invocations ([?] - means
> unverified).
> 1. -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> 2. [?]-> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511463#comment-17511463
]
Geode Integration commented on GEODE-10010:
---
Seen on support/1.14 in [integration-test-openjdk8
#37|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/integration-test-openjdk8/builds/37]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/integrationTest/1648063278/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648063278/integrationtestfiles-openjdk8-1.14.5-build.0938.tgz].
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrett Oglesby reassigned GEODE-10148: --- Assignee: Barrett Oglesby > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Assignee: Barrett Oglesby >Priority: Major > Labels: needsTriage > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10158) offheap can incorrectly disable or enable the query monitor
[ https://issues.apache.org/jira/browse/GEODE-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10158: -- Labels: needsTriage (was: ) > offheap can incorrectly disable or enable the query monitor > > > Key: GEODE-10158 > URL: https://issues.apache.org/jira/browse/GEODE-10158 > Project: Geode > Issue Type: Bug > Components: offheap, querying >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > Geode has a QueryMonitor that should be disabled if the resource manager's > critical-heap-threshold is 0 and enabled if it is > 0. > But critical-offheap-threshold tries to also disable and enable the > QueryMonitor. I think this is wrong since queries do not consume off-heap > memory. QueryMonitor's relationship with the ResourceManager should only care > about the critical-heap-threshold. The biggest risk is that this bug could > cause the QueryMonitor to be disabled even though critical-heap-threshold is > > 0. This would allow queries to consume heap memory when instead they should > have failed with a LowMemoryException. > To workaround this issue make sure that if you are using offheap that you > either leave both critical thresholds set to 0 or set both of them to a > non-zero value. > A simple fix for this exists. Delete this one line from OffHeapMemoryMonitor: > cache.setQueryMonitorRequiredForResourceManager(criticalThreshold != 0); > A better fix would be to remove the > InternalCache.setQueryMonitorRequiredForResourceManager method and instead > have GemFireCacheImpl.getQueryMonitor method ask it's InternalResourceManager > if it requires a QueryMonitor. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10158) offheap can incorrectly disable or enable the query monitor
Darrel Schneider created GEODE-10158: Summary: offheap can incorrectly disable or enable the query monitor Key: GEODE-10158 URL: https://issues.apache.org/jira/browse/GEODE-10158 Project: Geode Issue Type: Bug Components: offheap, querying Reporter: Darrel Schneider Geode has a QueryMonitor that should be disabled if the resource manager's critical-heap-threshold is 0 and enabled if it is > 0. But critical-offheap-threshold tries to also disable and enable the QueryMonitor. I think this is wrong since queries do not consume off-heap memory. QueryMonitor's relationship with the ResourceManager should only care about the critical-heap-threshold. The biggest risk is that this bug could cause the QueryMonitor to be disabled even though critical-heap-threshold is > 0. This would allow queries to consume heap memory when instead they should have failed with a LowMemoryException. To workaround this issue make sure that if you are using offheap that you either leave both critical thresholds set to 0 or set both of them to a non-zero value. A simple fix for this exists. Delete this one line from OffHeapMemoryMonitor: cache.setQueryMonitorRequiredForResourceManager(criticalThreshold != 0); A better fix would be to remove the InternalCache.setQueryMonitorRequiredForResourceManager method and instead have GemFireCacheImpl.getQueryMonitor method ask it's InternalResourceManager if it requires a QueryMonitor. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511454#comment-17511454 ] Anilkumar Gingade commented on GEODE-10148: --- >From Barry: >> The communication between servers and the JMX manager (locator) is async (a >> no-ack region). This test is most likely failing because of that. > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data
[
https://issues.apache.org/jira/browse/GEODE-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-10157:
---
Labels: (was: needsTriage)
> Add unit tests for all Delta classes in package
> org.apache.geode.redis.internal.data
>
>
> Key: GEODE-10157
> URL: https://issues.apache.org/jira/browse/GEODE-10157
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Expand on tests in
> {{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other
> delta-related classes in this package.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data
[
https://issues.apache.org/jira/browse/GEODE-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10157:
--
Labels: needsTriage (was: )
> Add unit tests for all Delta classes in package
> org.apache.geode.redis.internal.data
>
>
> Key: GEODE-10157
> URL: https://issues.apache.org/jira/browse/GEODE-10157
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> Expand on tests in
> {{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other
> delta-related classes in this package.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data
Jens Deppe created GEODE-10157:
--
Summary: Add unit tests for all Delta classes in package
org.apache.geode.redis.internal.data
Key: GEODE-10157
URL: https://issues.apache.org/jira/browse/GEODE-10157
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Jens Deppe
Expand on tests in
{{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other
delta-related classes in this package.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-10150: Labels: pull-request-available (was: blocks-1.15.0 pull-request-available) > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-10150. - Fix Version/s: 1.12.10 1.13.9 1.14.5 1.15.0 Resolution: Fixed Fixed in develop, back-ported to 1.14, 1.13, 1.12. > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511442#comment-17511442 ] ASF subversion and git services commented on GEODE-10150: - Commit f57421d909872834dd94e311948843cd9f47a916 in geode's branch refs/heads/support/1.12 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f57421d ] GEODE-10150: alter runtime command and change loglevel command docs bug & improvements (#7474) > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511440#comment-17511440 ] ASF subversion and git services commented on GEODE-10150: - Commit 8ac3d8217ab51910ba4199b0ef4eca61ebb96fe4 in geode's branch refs/heads/support/1.13 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ac3d82 ] GEODE-10150: alter runtime command and change loglevel command docs bug & improvements (#7474) > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10154) Benchmarks: PartitionedIndexedQueryBenchmark: net.schmizz.sshj.transport.TransportException: Server closed connection during identification exchange
[
https://issues.apache.org/jira/browse/GEODE-10154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511438#comment-17511438
]
Geode Integration commented on GEODE-10154:
---
Seen in [benchmark-with-security-manager
#222|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/222].
> Benchmarks: PartitionedIndexedQueryBenchmark:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
>
>
> Key: GEODE-10154
> URL: https://issues.apache.org/jira/browse/GEODE-10154
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/224]
> This same framework is reporting an error in GEODE-10153 and GEODE-10147
> {noformat}
> 02:36:47PartitionedIndexedQueryBenchmark > run() FAILED
> 02:36:47java.util.concurrent.CompletionException:
> java.io.UncheckedIOException: net.schmizz.sshj.transport.TransportException:
> Server closed connection during identification exchange
> 02:36:47at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> 02:36:47at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632)
> 02:36:47at
> java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> 02:36:47at
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> 02:36:47at
> java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> 02:36:47at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
> 02:36:47
> 02:36:47Caused by:
> 02:36:47java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> 02:36:47... 5 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 02:36:47at
> net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 02:36:47at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> 02:36:47... 6 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:214)
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 02:36:47... 10 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10153) Benchmarks: PartitionedPutAllBenchmark: net.schmizz.sshj.transport.TransportException: Connection reset
[
https://issues.apache.org/jira/browse/GEODE-10153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511437#comment-17511437
]
Geode Integration commented on GEODE-10153:
---
Seen in [benchmark-with-security-manager
#221|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/221].
> Benchmarks: PartitionedPutAllBenchmark:
> net.schmizz.sshj.transport.TransportException: Connection reset
>
>
> Key: GEODE-10153
> URL: https://issues.apache.org/jira/browse/GEODE-10153
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> This looks like GEODE-10147
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/223]
>
> {noformat}
> 2022-03-23 04:26:18.839 ERROR RemoteJVMFactory - Launching
> /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java -classpath
> .geode-performance/lib/SERVER-2/*
> -Djava.library.path=/home/geode/META-INF/native -DRMI_HOST=172.31.40.73
> -DRMI_PORT=3 -DJVM_ID=2 -DROLE=SERVER -DOUTPUT_DIR=output/SERVER-2
> -server -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true
> -Dgemfire.launcher.registerSignalHandlers=true -XX:+DisableExplicitGC -Xmx8g
> -Xms8g -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly
> -XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark
> -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseNUMA -XX:+ScavengeBeforeFullGC
> -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768
> -Dbenchmark.withSslProtocols= -Dbenchmark.withSslCiphers=
> org.apache.geode.perftest.jvms.rmi.ChildJVM on
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure$SshNode@3cad46e8Failed.
> 21:26:18net.schmizz.sshj.transport.TransportException: Connection reset
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 21:26:18 at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 21:26:18 at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.onNode(SshInfrastructure.java:86)
> 21:26:18 at
> org.apache.geode.perftest.jvms.JVMLauncher$1.run(JVMLauncher.java:68)
> 21:26:18Caused by: java.net.SocketException: Connection reset
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:210)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:141)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:224)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 21:26:18 ... 5 more
> 21:31:18
> 21:31:18PartitionedPutAllBenchmark > run() FAILED
> 21:31:18java.lang.IllegalStateException: Workers failed to start in 5
> minute
> 21:31:18at
> org.apache.geode.perftest.jvms.RemoteJVMFactory.launch(RemoteJVMFactory.java:133)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:97)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> 21:31:18at
> org.apache.geode.benchmark.tests.PartitionedPutAllBenchmark.run(PartitionedPutAllBenchmark.java:52)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10154) Benchmarks: PartitionedIndexedQueryBenchmark: net.schmizz.sshj.transport.TransportException: Server closed connection during identification exchange
[
https://issues.apache.org/jira/browse/GEODE-10154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511436#comment-17511436
]
Geode Integration commented on GEODE-10154:
---
Seen in [benchmark-with-security-manager
#221|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/221].
> Benchmarks: PartitionedIndexedQueryBenchmark:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
>
>
> Key: GEODE-10154
> URL: https://issues.apache.org/jira/browse/GEODE-10154
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/224]
> This same framework is reporting an error in GEODE-10153 and GEODE-10147
> {noformat}
> 02:36:47PartitionedIndexedQueryBenchmark > run() FAILED
> 02:36:47java.util.concurrent.CompletionException:
> java.io.UncheckedIOException: net.schmizz.sshj.transport.TransportException:
> Server closed connection during identification exchange
> 02:36:47at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> 02:36:47at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632)
> 02:36:47at
> java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> 02:36:47at
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> 02:36:47at
> java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> 02:36:47at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
> 02:36:47
> 02:36:47Caused by:
> 02:36:47java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> 02:36:47... 5 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 02:36:47at
> net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 02:36:47at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> 02:36:47... 6 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:214)
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 02:36:47... 10 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511435#comment-17511435 ] ASF subversion and git services commented on GEODE-10150: - Commit 90b163317420492e8fdd29ec1c10658d049d0ef7 in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=90b1633 ] GEODE-10150: alter runtime command and change loglevel command docs bug & improvements (#7474) > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10153) Benchmarks: PartitionedPutAllBenchmark: net.schmizz.sshj.transport.TransportException: Connection reset
[
https://issues.apache.org/jira/browse/GEODE-10153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511434#comment-17511434
]
Geode Integration commented on GEODE-10153:
---
Seen in [benchmark-with-security-manager
#223|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/223].
> Benchmarks: PartitionedPutAllBenchmark:
> net.schmizz.sshj.transport.TransportException: Connection reset
>
>
> Key: GEODE-10153
> URL: https://issues.apache.org/jira/browse/GEODE-10153
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> This looks like GEODE-10147
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/223]
>
> {noformat}
> 2022-03-23 04:26:18.839 ERROR RemoteJVMFactory - Launching
> /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java -classpath
> .geode-performance/lib/SERVER-2/*
> -Djava.library.path=/home/geode/META-INF/native -DRMI_HOST=172.31.40.73
> -DRMI_PORT=3 -DJVM_ID=2 -DROLE=SERVER -DOUTPUT_DIR=output/SERVER-2
> -server -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true
> -Dgemfire.launcher.registerSignalHandlers=true -XX:+DisableExplicitGC -Xmx8g
> -Xms8g -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly
> -XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark
> -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseNUMA -XX:+ScavengeBeforeFullGC
> -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768
> -Dbenchmark.withSslProtocols= -Dbenchmark.withSslCiphers=
> org.apache.geode.perftest.jvms.rmi.ChildJVM on
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure$SshNode@3cad46e8Failed.
> 21:26:18net.schmizz.sshj.transport.TransportException: Connection reset
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 21:26:18 at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 21:26:18 at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.onNode(SshInfrastructure.java:86)
> 21:26:18 at
> org.apache.geode.perftest.jvms.JVMLauncher$1.run(JVMLauncher.java:68)
> 21:26:18Caused by: java.net.SocketException: Connection reset
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:210)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:141)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:224)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 21:26:18 ... 5 more
> 21:31:18
> 21:31:18PartitionedPutAllBenchmark > run() FAILED
> 21:31:18java.lang.IllegalStateException: Workers failed to start in 5
> minute
> 21:31:18at
> org.apache.geode.perftest.jvms.RemoteJVMFactory.launch(RemoteJVMFactory.java:133)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:97)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> 21:31:18at
> org.apache.geode.benchmark.tests.PartitionedPutAllBenchmark.run(PartitionedPutAllBenchmark.java:52)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10154) Benchmarks: PartitionedIndexedQueryBenchmark: net.schmizz.sshj.transport.TransportException: Server closed connection during identification exchange
[
https://issues.apache.org/jira/browse/GEODE-10154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511432#comment-17511432
]
Geode Integration commented on GEODE-10154:
---
Seen in [benchmark-with-security-manager
#224|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/224].
> Benchmarks: PartitionedIndexedQueryBenchmark:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
>
>
> Key: GEODE-10154
> URL: https://issues.apache.org/jira/browse/GEODE-10154
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/224]
> This same framework is reporting an error in GEODE-10153 and GEODE-10147
> {noformat}
> 02:36:47PartitionedIndexedQueryBenchmark > run() FAILED
> 02:36:47java.util.concurrent.CompletionException:
> java.io.UncheckedIOException: net.schmizz.sshj.transport.TransportException:
> Server closed connection during identification exchange
> 02:36:47at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> 02:36:47at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632)
> 02:36:47at
> java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> 02:36:47at
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> 02:36:47at
> java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> 02:36:47at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
> 02:36:47
> 02:36:47Caused by:
> 02:36:47java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> 02:36:47... 5 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 02:36:47at
> net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 02:36:47at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> 02:36:47... 6 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:214)
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 02:36:47... 10 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10154) Benchmarks: PartitionedIndexedQueryBenchmark: net.schmizz.sshj.transport.TransportException: Server closed connection during identification exchange
[
https://issues.apache.org/jira/browse/GEODE-10154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511433#comment-17511433
]
Geode Integration commented on GEODE-10154:
---
Seen in [benchmark-with-security-manager
#223|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/223].
> Benchmarks: PartitionedIndexedQueryBenchmark:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
>
>
> Key: GEODE-10154
> URL: https://issues.apache.org/jira/browse/GEODE-10154
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/224]
> This same framework is reporting an error in GEODE-10153 and GEODE-10147
> {noformat}
> 02:36:47PartitionedIndexedQueryBenchmark > run() FAILED
> 02:36:47java.util.concurrent.CompletionException:
> java.io.UncheckedIOException: net.schmizz.sshj.transport.TransportException:
> Server closed connection during identification exchange
> 02:36:47at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> 02:36:47at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632)
> 02:36:47at
> java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> 02:36:47at
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> 02:36:47at
> java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> 02:36:47at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
> 02:36:47
> 02:36:47Caused by:
> 02:36:47java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> 02:36:47... 5 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 02:36:47at
> net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 02:36:47at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> 02:36:47... 6 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:214)
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 02:36:47... 10 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10156) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED
Eric Shu created GEODE-10156: Summary: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED Key: GEODE-10156 URL: https://issues.apache.org/jira/browse/GEODE-10156 Project: Geode Issue Type: Bug Components: tests Reporter: Eric Shu org.opentest4j.AssertionFailedError: [Exit value from process started by [4f44cb7de3b710f1: gfsh -e start locator --name=loc1 --port=20846 --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20847 -e start locator --name=loc2 --port=20848 --http-service-port=0 --locators=localhost[20846] --J=-Dgemfire.jmx-manager-port=20849 -e start server --name=server1 --server-port=20850 --locators=localhost[20846] -e start server --name=server2 --server-port=20851 --locators=localhost[20846] -e deploy --dir=/tmp/junit4947263696282150978/junit6257623670577599443]] expected: 0 but was: 1 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) at org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) at org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153) at org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at org.junit.runner.JUnitCore.run(JUnitCore.java:115) at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) at org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) at org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108) at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88) at
[jira] [Updated] (GEODE-10156) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10156: -- Labels: needsTriage (was: ) > RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] > FAILED > - > > Key: GEODE-10156 > URL: https://issues.apache.org/jira/browse/GEODE-10156 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.opentest4j.AssertionFailedError: [Exit value from process started by > [4f44cb7de3b710f1: gfsh -e start locator --name=loc1 --port=20846 > --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20847 -e start locator > --name=loc2 --port=20848 --http-service-port=0 --locators=localhost[20846] > --J=-Dgemfire.jmx-manager-port=20849 -e start server --name=server1 > --server-port=20850 --locators=localhost[20846] -e start server > --name=server2 --server-port=20851 --locators=localhost[20846] -e deploy > --dir=/tmp/junit4947263696282150978/junit6257623670577599443]] > expected: 0 > but was: 1 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) > at > org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153) > at > org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:93) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at > org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) > at > org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) > at >
[jira] [Commented] (GEODE-10156) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511420#comment-17511420 ] Geode Integration commented on GEODE-10156: --- Seen in [upgrade-test-openjdk8 #228|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/228] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1022/test-results/upgradeTest/1648014599/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1022/test-artifacts/1648014599/upgradetestfiles-openjdk8-1.15.0-build.1022.tgz]. > RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] > FAILED > - > > Key: GEODE-10156 > URL: https://issues.apache.org/jira/browse/GEODE-10156 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.opentest4j.AssertionFailedError: [Exit value from process started by > [4f44cb7de3b710f1: gfsh -e start locator --name=loc1 --port=20846 > --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20847 -e start locator > --name=loc2 --port=20848 --http-service-port=0 --locators=localhost[20846] > --J=-Dgemfire.jmx-manager-port=20849 -e start server --name=server1 > --server-port=20850 --locators=localhost[20846] -e start server > --name=server2 --server-port=20851 --locators=localhost[20846] -e deploy > --dir=/tmp/junit4947263696282150978/junit6257623670577599443]] > expected: 0 > but was: 1 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) > at > org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153) > at > org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:93) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at
[jira] [Assigned] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-10155: - Assignee: Alberto Gomez > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage > > If a Geode client executes a server function with a timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10155: -- Labels: needsTriage (was: ) > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > If a Geode client executes a server function with a timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
Alberto Gomez created GEODE-10155: - Summary: ServerConnection thread hangs when client function execution times-out Key: GEODE-10155 URL: https://issues.apache.org/jira/browse/GEODE-10155 Project: Geode Issue Type: Bug Components: core, functions Reporter: Alberto Gomez If a Geode client executes a server function with a timeout and the function is handled in the Geode server by a "Function Execution Processor" thread (for example by calling the function with onRegion() on a partitioned region without a filter) and the function times-out before the server has answered back with all the results then the ServerConnection thread that originally started to handle the function execution will be stuck forever. If this happens several times and the max-threads parameters is set to a value greater than 0, the server will eventually run out of ServerConnection threads and will not be able to process more client requests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10154) Benchmarks: PartitionedIndexedQueryBenchmark: net.schmizz.sshj.transport.TransportException: Server closed connection during identification exchange
[
https://issues.apache.org/jira/browse/GEODE-10154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10154:
--
Labels: needsTriage (was: )
> Benchmarks: PartitionedIndexedQueryBenchmark:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
>
>
> Key: GEODE-10154
> URL: https://issues.apache.org/jira/browse/GEODE-10154
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/224]
> This same framework is reporting an error in GEODE-10153 and GEODE-10147
> {noformat}
> 02:36:47PartitionedIndexedQueryBenchmark > run() FAILED
> 02:36:47java.util.concurrent.CompletionException:
> java.io.UncheckedIOException: net.schmizz.sshj.transport.TransportException:
> Server closed connection during identification exchange
> 02:36:47at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> 02:36:47at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632)
> 02:36:47at
> java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
> 02:36:47at
> java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
> 02:36:47at
> java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
> 02:36:47at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
> 02:36:47
> 02:36:47Caused by:
> 02:36:47java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> 02:36:47at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> 02:36:47... 5 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 02:36:47at
> net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 02:36:47at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 02:36:47at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> 02:36:47... 6 more
> 02:36:47
> 02:36:47Caused by:
> 02:36:47net.schmizz.sshj.transport.TransportException: Server
> closed connection during identification exchange
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:214)
> 02:36:47at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 02:36:47... 10 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10154) Benchmarks: PartitionedIndexedQueryBenchmark: net.schmizz.sshj.transport.TransportException: Server closed connection during identification exchange
Mark Hanson created GEODE-10154:
---
Summary: Benchmarks: PartitionedIndexedQueryBenchmark:
net.schmizz.sshj.transport.TransportException: Server closed connection during
identification exchange
Key: GEODE-10154
URL: https://issues.apache.org/jira/browse/GEODE-10154
Project: Geode
Issue Type: Bug
Components: benchmarks
Affects Versions: 1.15.0
Reporter: Mark Hanson
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-security-manager/builds/224]
This same framework is reporting an error in GEODE-10153 and GEODE-10147
{noformat}
02:36:47PartitionedIndexedQueryBenchmark > run() FAILED
02:36:47java.util.concurrent.CompletionException:
java.io.UncheckedIOException: net.schmizz.sshj.transport.TransportException:
Server closed connection during identification exchange
02:36:47at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
02:36:47at
java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
02:36:47at
java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
02:36:47at
java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1632)
02:36:47at
java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
02:36:47at
java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
02:36:47at
java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
02:36:47at
java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:175)
02:36:47
02:36:47Caused by:
02:36:47java.io.UncheckedIOException:
net.schmizz.sshj.transport.TransportException: Server closed connection during
identification exchange
02:36:47at
org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
02:36:47at
java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
02:36:47... 5 more
02:36:47
02:36:47Caused by:
02:36:47net.schmizz.sshj.transport.TransportException: Server
closed connection during identification exchange
02:36:47at
net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
02:36:47at
net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
02:36:47at
net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
02:36:47at
org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
02:36:47at
org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
02:36:47... 6 more
02:36:47
02:36:47Caused by:
02:36:47net.schmizz.sshj.transport.TransportException: Server
closed connection during identification exchange
02:36:47at
net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:214)
02:36:47at
net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
02:36:47... 10 more {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511414#comment-17511414
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#220|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/220].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10153) Benchmarks: PartitionedPutAllBenchmark: net.schmizz.sshj.transport.TransportException: Connection reset
[
https://issues.apache.org/jira/browse/GEODE-10153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511411#comment-17511411
]
Geode Integration commented on GEODE-10153:
---
Seen in [benchmark-base
#223|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/223].
> Benchmarks: PartitionedPutAllBenchmark:
> net.schmizz.sshj.transport.TransportException: Connection reset
>
>
> Key: GEODE-10153
> URL: https://issues.apache.org/jira/browse/GEODE-10153
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> This looks like GEODE-10147
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/223]
>
> {noformat}
> 2022-03-23 04:26:18.839 ERROR RemoteJVMFactory - Launching
> /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java -classpath
> .geode-performance/lib/SERVER-2/*
> -Djava.library.path=/home/geode/META-INF/native -DRMI_HOST=172.31.40.73
> -DRMI_PORT=3 -DJVM_ID=2 -DROLE=SERVER -DOUTPUT_DIR=output/SERVER-2
> -server -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true
> -Dgemfire.launcher.registerSignalHandlers=true -XX:+DisableExplicitGC -Xmx8g
> -Xms8g -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly
> -XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark
> -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseNUMA -XX:+ScavengeBeforeFullGC
> -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768
> -Dbenchmark.withSslProtocols= -Dbenchmark.withSslCiphers=
> org.apache.geode.perftest.jvms.rmi.ChildJVM on
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure$SshNode@3cad46e8Failed.
> 21:26:18net.schmizz.sshj.transport.TransportException: Connection reset
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 21:26:18 at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 21:26:18 at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.onNode(SshInfrastructure.java:86)
> 21:26:18 at
> org.apache.geode.perftest.jvms.JVMLauncher$1.run(JVMLauncher.java:68)
> 21:26:18Caused by: java.net.SocketException: Connection reset
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:210)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:141)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:224)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 21:26:18 ... 5 more
> 21:31:18
> 21:31:18PartitionedPutAllBenchmark > run() FAILED
> 21:31:18java.lang.IllegalStateException: Workers failed to start in 5
> minute
> 21:31:18at
> org.apache.geode.perftest.jvms.RemoteJVMFactory.launch(RemoteJVMFactory.java:133)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:97)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> 21:31:18at
> org.apache.geode.benchmark.tests.PartitionedPutAllBenchmark.run(PartitionedPutAllBenchmark.java:52)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10153) Benchmarks: PartitionedPutAllBenchmark: net.schmizz.sshj.transport.TransportException: Connection reset
[
https://issues.apache.org/jira/browse/GEODE-10153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10153:
--
Labels: needsTriage (was: )
> Benchmarks: PartitionedPutAllBenchmark:
> net.schmizz.sshj.transport.TransportException: Connection reset
>
>
> Key: GEODE-10153
> URL: https://issues.apache.org/jira/browse/GEODE-10153
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> This looks like GEODE-10147
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/223]
>
> {noformat}
> 2022-03-23 04:26:18.839 ERROR RemoteJVMFactory - Launching
> /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java -classpath
> .geode-performance/lib/SERVER-2/*
> -Djava.library.path=/home/geode/META-INF/native -DRMI_HOST=172.31.40.73
> -DRMI_PORT=3 -DJVM_ID=2 -DROLE=SERVER -DOUTPUT_DIR=output/SERVER-2
> -server -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true
> -Dgemfire.launcher.registerSignalHandlers=true -XX:+DisableExplicitGC -Xmx8g
> -Xms8g -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly
> -XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark
> -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseNUMA -XX:+ScavengeBeforeFullGC
> -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768
> -Dbenchmark.withSslProtocols= -Dbenchmark.withSslCiphers=
> org.apache.geode.perftest.jvms.rmi.ChildJVM on
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure$SshNode@3cad46e8Failed.
> 21:26:18net.schmizz.sshj.transport.TransportException: Connection reset
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> 21:26:18 at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> 21:26:18 at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> 21:26:18 at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.onNode(SshInfrastructure.java:86)
> 21:26:18 at
> org.apache.geode.perftest.jvms.JVMLauncher$1.run(JVMLauncher.java:68)
> 21:26:18Caused by: java.net.SocketException: Connection reset
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:210)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:141)
> 21:26:18 at java.net.SocketInputStream.read(SocketInputStream.java:224)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> 21:26:18 at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> 21:26:18 ... 5 more
> 21:31:18
> 21:31:18PartitionedPutAllBenchmark > run() FAILED
> 21:31:18java.lang.IllegalStateException: Workers failed to start in 5
> minute
> 21:31:18at
> org.apache.geode.perftest.jvms.RemoteJVMFactory.launch(RemoteJVMFactory.java:133)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:97)
> 21:31:18at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> 21:31:18at
> org.apache.geode.benchmark.tests.PartitionedPutAllBenchmark.run(PartitionedPutAllBenchmark.java:52)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10153) Benchmarks: PartitionedPutAllBenchmark: net.schmizz.sshj.transport.TransportException: Connection reset
Mark Hanson created GEODE-10153:
---
Summary: Benchmarks: PartitionedPutAllBenchmark:
net.schmizz.sshj.transport.TransportException: Connection reset
Key: GEODE-10153
URL: https://issues.apache.org/jira/browse/GEODE-10153
Project: Geode
Issue Type: Bug
Components: benchmarks
Affects Versions: 1.15.0
Reporter: Mark Hanson
This looks like GEODE-10147
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/223]
{noformat}
2022-03-23 04:26:18.839 ERROR RemoteJVMFactory - Launching
/usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java -classpath
.geode-performance/lib/SERVER-2/*
-Djava.library.path=/home/geode/META-INF/native -DRMI_HOST=172.31.40.73
-DRMI_PORT=3 -DJVM_ID=2 -DROLE=SERVER -DOUTPUT_DIR=output/SERVER-2 -server
-Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true
-Dgemfire.launcher.registerSignalHandlers=true -XX:+DisableExplicitGC -Xmx8g
-Xms8g -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly
-XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark
-XX:CMSInitiatingOccupancyFraction=60 -XX:+UseNUMA -XX:+ScavengeBeforeFullGC
-XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768
-Dbenchmark.withSslProtocols= -Dbenchmark.withSslCiphers=
org.apache.geode.perftest.jvms.rmi.ChildJVM on
org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure$SshNode@3cad46e8Failed.
21:26:18net.schmizz.sshj.transport.TransportException: Connection reset
21:26:18at
net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
21:26:18at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
21:26:18at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
21:26:18at
org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
21:26:18at
org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.onNode(SshInfrastructure.java:86)
21:26:18at
org.apache.geode.perftest.jvms.JVMLauncher$1.run(JVMLauncher.java:68)
21:26:18Caused by: java.net.SocketException: Connection reset
21:26:18at java.net.SocketInputStream.read(SocketInputStream.java:210)
21:26:18at java.net.SocketInputStream.read(SocketInputStream.java:141)
21:26:18at java.net.SocketInputStream.read(SocketInputStream.java:224)
21:26:18at
net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
21:26:18at
net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
21:26:18... 5 more
21:31:18
21:31:18PartitionedPutAllBenchmark > run() FAILED
21:31:18java.lang.IllegalStateException: Workers failed to start in 5 minute
21:31:18at
org.apache.geode.perftest.jvms.RemoteJVMFactory.launch(RemoteJVMFactory.java:133)
21:31:18at
org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:97)
21:31:18at
org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
21:31:18at
org.apache.geode.benchmark.tests.PartitionedPutAllBenchmark.run(PartitionedPutAllBenchmark.java:52)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10134) SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10134:
---
Labels: Java17 pull-request-available (was: Java17)
> SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
>
>
> Key: GEODE-10134
> URL: https://issues.apache.org/jira/browse/GEODE-10134
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
>
> On JDK 17, the classes of proxies are created in dynamically created
> packages. The current implemention of
> {{SanctionedSerializablesFilterPattern}} does not recognize those packages,
> and so rejects all proxy objects.
> So far I've seen two dynamically created proxy packages:
> - {{jdk.proxy2}}
> - {{jdk.proxy3}}
> Adding {{"jdk.proxy*"}} to the {{SanctionedSerializablesFilterPattern}} fixes
> the problem, at the risk of accepting an overly broad set of classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511407#comment-17511407
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-with-ssl
#221|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-ssl/builds/221].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511405#comment-17511405
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-with-ssl
#220|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-ssl/builds/220].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511404#comment-17511404
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-with-ssl
#222|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-ssl/builds/222].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511403#comment-17511403
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#222|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/222].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511402#comment-17511402
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#221|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/221].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511401#comment-17511401
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-with-ssl
#219|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-ssl/builds/219].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511400#comment-17511400
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-with-ssl
#218|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-with-ssl/builds/218].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10134) SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10134:
--
Assignee: Dale Emery
> SanctionedSerializablesFilterPattern does not accept proxy classes on JDK 17
>
>
> Key: GEODE-10134
> URL: https://issues.apache.org/jira/browse/GEODE-10134
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17
>
> On JDK 17, the classes of proxies are created in dynamically created
> packages. The current implemention of
> {{SanctionedSerializablesFilterPattern}} does not recognize those packages,
> and so rejects all proxy objects.
> So far I've seen two dynamically created proxy packages:
> - {{jdk.proxy2}}
> - {{jdk.proxy3}}
> Adding {{"jdk.proxy*"}} to the {{SanctionedSerializablesFilterPattern}} fixes
> the problem, at the risk of accepting an overly broad set of classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8791) CI Failure: Jetty9CachingClientServerTest.attributesCanBeReplaced FAILED
[
https://issues.apache.org/jira/browse/GEODE-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511393#comment-17511393
]
Geode Integration commented on GEODE-8791:
--
Seen on support/1.13 in [distributed-test-openjdk11
#33|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/33]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0664/test-results/distributedTest/1648030999/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0664/test-artifacts/1648030999/distributedtestfiles-openjdk11-1.13.9-build.0664.tgz].
> CI Failure: Jetty9CachingClientServerTest.attributesCanBeReplaced FAILED
>
>
> Key: GEODE-8791
> URL: https://issues.apache.org/jira/browse/GEODE-8791
> Project: Geode
> Issue Type: Bug
> Components: http session
>Reporter: Eric Shu
>Priority: Major
>
> Test run is at:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/660
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in org.apache.geode.session.tests.CargoTestBase
> expected:<"[Bar]"> but was:<"[Foo]"> within 5 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.session.tests.CargoTestBase.attributesCanBeReplaced(CargoTestBase.java:402)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511392#comment-17511392
]
Geode Integration commented on GEODE-8760:
--
Seen on support/1.14 in [benchmark-base
#34|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/benchmark-base/builds/34].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511380#comment-17511380
]
Geode Integration commented on GEODE-8760:
--
Seen on support/1.14 in [benchmark-with-ssl
#33|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/benchmark-with-ssl/builds/33].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8762) Thread Monitoring Service to include reply waiting member info as part of stuck thread details
[ https://issues.apache.org/jira/browse/GEODE-8762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511379#comment-17511379 ] Geode Integration commented on GEODE-8762: -- Seen on support/1.14 in [benchmark-with-ssl #33|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/benchmark-with-ssl/builds/33]. > Thread Monitoring Service to include reply waiting member info as part of > stuck thread details > -- > > Key: GEODE-8762 > URL: https://issues.apache.org/jira/browse/GEODE-8762 > Project: Geode > Issue Type: Improvement > Components: regions >Affects Versions: 1.14.0 >Reporter: Anilkumar Gingade >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > Thread Monitoring Service provides information about the stuck thread with > their stack dump. It will be nice to have information about the members a > thread is waiting response from as part of the stuck thread details. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10126: --- Labels: pull-request-available (was: ) > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511339#comment-17511339 ] Barrett Oglesby commented on GEODE-10144: - This issue comes down to a few factors: - The default PoolFactory::DEFAULT_SUBSCRIPTION_ACK_INTERVAL of 100 seconds means all the events stay on the queue for entire test. This means that every time the client disconnects, the server starts over again processing the queue from the beginning. - The NC client is version GFE 9.0 (earlier) so no ClientReAuthenticateMessage is sent to it when a AuthenticationExpiredException occurs. The server waits anyway in case new credentials are sent through another operation. - With the new changes, the server waits 5 seconds to be notified of a re-auth. If no re-auth occurs, it waits the entire 5 seconds. - With the old code, the server waits 200 ms before attempting to process the event again (which includes asking for authorization again). The SimulatedExpirationSecurityManager randomly decides whether to authorize the event. 99% of the time, it returns true. So, the second request will almost always return true. - So without any external event (like new credentials): -- With the the old code, the Message Dispatcher processes the event successfully after 200 ms with no client disconnect -- With the new code, the Message Dispatcher waits 5 seconds and then disconnects the client > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10150) alter runtime command and change loglevel command docs bug & improvements
[ https://issues.apache.org/jira/browse/GEODE-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511323#comment-17511323 ] ASF subversion and git services commented on GEODE-10150: - Commit d3d6915d40eb9a4913e0bafd60eb08ed041af539 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d3d6915 ] GEODE-10150: alter runtime command and change loglevel command docs bug & improvements (#7474) > alter runtime command and change loglevel command docs bug & improvements > - > > Key: GEODE-10150 > URL: https://issues.apache.org/jira/browse/GEODE-10150 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.4 >Reporter: Deepak Khopade >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > The parameters information for gfsh>alter runtime --log-level shows an > incorrect parameter name in a table where all parameter's description is > provided. The actual expects --log-level but the row in a table says > --loglevel. See the screenshot attached. > (https://gemfire.docs.pivotal.io/910/geode/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B) > Another important point is, we should add a line on both the links below to > state the difference when using these commands (alter runtime and change > loglevel). > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html#topic_7E6B7E1B972D4F418CB45354D1089C2B > https://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/change.html > When I tried both of these commands, it has been found that for locator we > need to use gfsh>change loglevel --loglevel=config --member=locator and > gfsh>alter runtime --log-level for cache server members. The alter runtime > --log-level command doesn't work for Locators. > So adding a line or changing an existing line on the docs will help new > customers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
