[jira] [Commented] (GEODE-3185) CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3 tests failing with java.lang.AssertionError: Null entry
[
https://issues.apache.org/jira/browse/GEODE-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163827#comment-16163827
]
ASF subversion and git services commented on GEODE-3185:
Commit 6c27086f6025f66a1b7ecd31c4ec1348dfde413e in geode's branch
refs/heads/feature/GEODE-3185 from [~lgallinat]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6c27086 ]
GEODE-3185 The windows restore script now cds to the directory containing the
script.
- This makes the windows restore script similar to the unix restore script
- The restore script uses relative path names, so the cd is required for it to
work.
> CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3
> tests failing with java.lang.AssertionError: Null entry
>
>
> Key: GEODE-3185
> URL: https://issues.apache.org/jira/browse/GEODE-3185
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Reporter: Lynn Gallinat
>Assignee: Lynn Gallinat
> Labels: storage_3, windows_test
>
> {noformat}
> org.apache.geode.internal.cache.BackupJUnitTest > testBackupAndRecover FAILED
> java.lang.AssertionError: Null entry 512
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.backupAndRecover(BackupJUnitTest.java:229)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.testBackupAndRecover(BackupJUnitTest.java:126)
> org.apache.geode.internal.cache.BackupJUnitTest > testCompactionDuringBackup
> FAILED
> java.lang.AssertionError: Null entry 0
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.testCompactionDuringBackup(BackupJUnitTest.java:309)
> org.apache.geode.internal.cache.BackupJUnitTest >
> testBackupAndRecoverOldConfig FAILED
> java.lang.AssertionError: Null entry 512
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.backupAndRecover(BackupJUnitTest.java:229)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.testBackupAndRecoverOldConfig(BackupJUnitTest.java:136)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-3610) RoundTripCacheConnectionTest should not use test name to run with SSL
Alexander Murmann created GEODE-3610: Summary: RoundTripCacheConnectionTest should not use test name to run with SSL Key: GEODE-3610 URL: https://issues.apache.org/jira/browse/GEODE-3610 Project: Geode Issue Type: Task Reporter: Alexander Murmann -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3185) CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3 tests failing with java.lang.AssertionError: Null entry
[
https://issues.apache.org/jira/browse/GEODE-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163898#comment-16163898
]
ASF subversion and git services commented on GEODE-3185:
Commit a5c67bae8546fd66dbb2b374015e34196a713d66 in geode's branch
refs/heads/feature/GEODE-3185-2 from [~lgallinat]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a5c67ba ]
GEODE-3185: Fixes CI failures in windows in
org.apache.geode.internal.cache.BackupJUnitTest
The windows restore script now cds to the directory containing the script.
This makes the windows restore script similar to the unix restore script
The restore script uses relative path names, so the cd is required for it to
work.
> CI failure (windows): org.apache.geode.internal.cache.BackupJUnitTest, 3
> tests failing with java.lang.AssertionError: Null entry
>
>
> Key: GEODE-3185
> URL: https://issues.apache.org/jira/browse/GEODE-3185
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Reporter: Lynn Gallinat
>Assignee: Lynn Gallinat
> Labels: storage_3, windows_test
>
> {noformat}
> org.apache.geode.internal.cache.BackupJUnitTest > testBackupAndRecover FAILED
> java.lang.AssertionError: Null entry 512
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.backupAndRecover(BackupJUnitTest.java:229)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.testBackupAndRecover(BackupJUnitTest.java:126)
> org.apache.geode.internal.cache.BackupJUnitTest > testCompactionDuringBackup
> FAILED
> java.lang.AssertionError: Null entry 0
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.testCompactionDuringBackup(BackupJUnitTest.java:309)
> org.apache.geode.internal.cache.BackupJUnitTest >
> testBackupAndRecoverOldConfig FAILED
> java.lang.AssertionError: Null entry 512
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.validateEntriesExist(BackupJUnitTest.java:354)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.backupAndRecover(BackupJUnitTest.java:229)
> at
> org.apache.geode.internal.cache.BackupJUnitTest.testBackupAndRecoverOldConfig(BackupJUnitTest.java:136)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GEODE-3602) Support for timestamp formats like this (yyyy-MM-dd' 'HH:mm:ss.SSSSSS) which is the default in Greenplum
[ https://issues.apache.org/jira/browse/GEODE-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amith Nambiar resolved GEODE-3602. -- Resolution: Invalid This is not a Geode issue, filing it under the Gemfire-Greenplum connector project. Sorry about that. > Support for timestamp formats like this (-MM-dd' 'HH:mm:ss.SS) which > is the default in Greenplum > > > Key: GEODE-3602 > URL: https://issues.apache.org/jira/browse/GEODE-3602 > Project: Geode > Issue Type: Improvement >Reporter: Amith Nambiar >Priority: Minor > > Currently the connector does not support the format (-MM-dd' > 'HH:mm:ss.SS) which is the default timestamp (timestamp without time > zone) format in Greenplum. > INSERT INTO bookings VALUES (1, now()::timestamp); > Results in a value for timestamp like this one: 2017-07-17 09:08:09.505397 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3602) Support for timestamp formats like this (yyyy-MM-dd' 'HH:mm:ss.SSSSSS) which is the default in Greenplum
Amith Nambiar created GEODE-3602: Summary: Support for timestamp formats like this (-MM-dd' 'HH:mm:ss.SS) which is the default in Greenplum Key: GEODE-3602 URL: https://issues.apache.org/jira/browse/GEODE-3602 Project: Geode Issue Type: Improvement Reporter: Amith Nambiar Currently the connector does not support the format (-MM-dd' 'HH:mm:ss.SS) which is the default timestamp format in Greenplum. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3602) Support for timestamp formats like this (yyyy-MM-dd' 'HH:mm:ss.SSSSSS) which is the default in Greenplum
[ https://issues.apache.org/jira/browse/GEODE-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amith Nambiar updated GEODE-3602: - Description: Currently the connector does not support the format (-MM-dd' 'HH:mm:ss.SS) which is the default timestamp (timestamp without time zone) format in Greenplum. INSERT INTO bookings VALUES (1, now()::timestamp); Results in a value for timestamp like this one: 2017-07-17 09:08:09.505397 was:Currently the connector does not support the format (-MM-dd' 'HH:mm:ss.SS) which is the default timestamp format in Greenplum. > Support for timestamp formats like this (-MM-dd' 'HH:mm:ss.SS) which > is the default in Greenplum > > > Key: GEODE-3602 > URL: https://issues.apache.org/jira/browse/GEODE-3602 > Project: Geode > Issue Type: Improvement >Reporter: Amith Nambiar > > Currently the connector does not support the format (-MM-dd' > 'HH:mm:ss.SS) which is the default timestamp (timestamp without time > zone) format in Greenplum. > INSERT INTO bookings VALUES (1, now()::timestamp); > Results in a value for timestamp like this one: 2017-07-17 09:08:09.505397 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3602) Support for timestamp formats like this (yyyy-MM-dd' 'HH:mm:ss.SSSSSS) which is the default in Greenplum
[ https://issues.apache.org/jira/browse/GEODE-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amith Nambiar updated GEODE-3602: - Priority: Minor (was: Major) > Support for timestamp formats like this (-MM-dd' 'HH:mm:ss.SS) which > is the default in Greenplum > > > Key: GEODE-3602 > URL: https://issues.apache.org/jira/browse/GEODE-3602 > Project: Geode > Issue Type: Improvement >Reporter: Amith Nambiar >Priority: Minor > > Currently the connector does not support the format (-MM-dd' > 'HH:mm:ss.SS) which is the default timestamp (timestamp without time > zone) format in Greenplum. > INSERT INTO bookings VALUES (1, now()::timestamp); > Results in a value for timestamp like this one: 2017-07-17 09:08:09.505397 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (GEODE-3605) Remove deprecated methods from Public API.
[ https://issues.apache.org/jira/browse/GEODE-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett updated GEODE-3605: Issue Type: Task (was: Bug) > Remove deprecated methods from Public API. > -- > > Key: GEODE-3605 > URL: https://issues.apache.org/jira/browse/GEODE-3605 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob S. Barrett > > Remove deprecated methods on public API. > See: > CacheableDate.hpp -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3426) CI Rest test failures
[
https://issues.apache.org/jira/browse/GEODE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-3426:
---
Assignee: Patrick Rhomberg
> CI Rest test failures
> -
>
> Key: GEODE-3426
> URL: https://issues.apache.org/jira/browse/GEODE-3426
> Project: Geode
> Issue Type: Bug
> Components: rest (dev)
>Reporter: Bruce Schuchardt
>Assignee: Patrick Rhomberg
> Labels: ci
>
> A number of Rest tests are failing when running precheckin on Windows
> {noformat}
> org.apache.geode.rest.internal.web.controllers.RestAPIsQueryAndFEJUnitTest >
> testCreateAsJson FAILED
> java.lang.AssertionError: expected:<201> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsQueryAndFEJUnitTest.executeQueryTestCases(RestAPIsQueryAndFEJUnitTest.java:831)
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsQueryAndFEJUnitTest.testCreateAsJson(RestAPIsQueryAndFEJUnitTest.java:677)
> org.apache.geode.rest.internal.web.RestInterfaceJUnitTest >
> testRegionObjectWithDatePropertyAccessedWithRestApi FAILED
> org.springframework.web.client.ResourceAccessException: I/O error on GET
> request for "http://localhost:25877/gemfire-api/v1/People/1": stream is
> closed; nested exception is java.io.IOException: stream is closed
> at
> org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:666)
> at
> org.springframework.web.client.RestTemplate.execute(RestTemplate.java:613)
> at
> org.springframework.web.client.RestTemplate.getForObject(RestTemplate.java:287)
> at
> org.apache.geode.rest.internal.web.RestInterfaceJUnitTest.testRegionObjectWithDatePropertyAccessedWithRestApi(RestInterfaceJUnitTest.java:317)
> Caused by:
> java.io.IOException: stream is closed
> at
> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.ensureOpen(HttpURLConnection.java:3348)
> at
> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:3353)
> at java.io.FilterInputStream.read(FilterInputStream.java:83)
> at java.io.PushbackInputStream.read(PushbackInputStream.java:139)
> at
> org.springframework.web.client.MessageBodyClientHttpResponseWrapper.hasEmptyMessageBody(MessageBodyClientHttpResponseWrapper.java:97)
> at
> org.springframework.web.client.HttpMessageConverterExtractor.extractData(HttpMessageConverterExtractor.java:82)
> at
> org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:655)
> ... 3 more
> org.apache.geode.rest.internal.web.RestServersJUnitTest > testGet FAILED
> org.junit.ComparisonFailure: expected:<[200]> but was:<[503]>
> 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.rest.internal.web.RestServersJUnitTest.testGet(RestServersJUnitTest.java:49)
> org.apache.geode.rest.internal.web.RestServersJUnitTest >
> testServerStartedOnDefaultPort FAILED
> org.json.JSONException: Value of type java.lang.String cannot be
> converted to JSONArray
> at org.json.JSON.typeMismatch(JSON.java:108)
> at org.json.JSONArray.(JSONArray.java:85)
> at
> org.apache.geode.rest.internal.web.GeodeRestClient.getJsonArray(GeodeRestClient.java:99)
> at
> org.apache.geode.rest.internal.web.RestServersJUnitTest.testServerStartedOnDefaultPort(RestServersJUnitTest.java:55)
> org.apache.geode.rest.internal.web.SwaggerVerificationTest > isSwaggerRunning
> FAILED
> java.lang.AssertionError:
> Expected: is <200>
> but: was <503>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:956)
> at org.junit.Assert.assertThat(Assert.java:923)
> at
> org.apache.geode.rest.internal.web.SwaggerVerificationTest.isSwaggerRunning(SwaggerVerificationTest.java:44)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-3605) Remove deprecated methods from Public API.
Jacob S. Barrett created GEODE-3605: --- Summary: Remove deprecated methods from Public API. Key: GEODE-3605 URL: https://issues.apache.org/jira/browse/GEODE-3605 Project: Geode Issue Type: Bug Components: native client Reporter: Jacob S. Barrett Remove deprecated methods on public API. See: CacheableDate.hpp -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3604) Refactor new protobuf protocol code, to be less intrusive on core
Udo Kohlmeyer created GEODE-3604: Summary: Refactor new protobuf protocol code, to be less intrusive on core Key: GEODE-3604 URL: https://issues.apache.org/jira/browse/GEODE-3604 Project: Geode Issue Type: Improvement Components: client/server Reporter: Udo Kohlmeyer -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3240) User can set a LuceneSerializer through the Java API
[ https://issues.apache.org/jira/browse/GEODE-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163628#comment-16163628 ] ASF subversion and git services commented on GEODE-3240: Commit 1a85faeb33d0c3874a775f6ce9a3d612c689e399 in geode's branch refs/heads/feature/GEODE-3240 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1a85fae ] GEODE-3240: add integration test > User can set a LuceneSerializer through the Java API > - > > Key: GEODE-3240 > URL: https://issues.apache.org/jira/browse/GEODE-3240 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Dan Smith > > As a user, I should be able to call LuceneIndexFactory.setLuceneSerializer > and pass my own LuceneSerializer when creating a lucene index. > The API for LuceneSerializer should be as specified on the wiki page. > Acceptance: > User can create a LuceneSerializer with the Java API and the LuceneSerializer > gets invoked. The documents returned by the LuceneSerializer are stored in > the index. > If objects are stored in the region as serialized PDX objects, they are > passed to the serializer as PdxInstance objects, rather than being > deserialized (Or should this be an option??) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3240) User can set a LuceneSerializer through the Java API
[ https://issues.apache.org/jira/browse/GEODE-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163635#comment-16163635 ] ASF subversion and git services commented on GEODE-3240: Commit 523375fe564654b923409d79af3f97b8ec07c6ed in geode's branch refs/heads/feature/GEODE-3240 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=523375f ] GEODE-3240: let the integration test code to use different fields > User can set a LuceneSerializer through the Java API > - > > Key: GEODE-3240 > URL: https://issues.apache.org/jira/browse/GEODE-3240 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Dan Smith > > As a user, I should be able to call LuceneIndexFactory.setLuceneSerializer > and pass my own LuceneSerializer when creating a lucene index. > The API for LuceneSerializer should be as specified on the wiki page. > Acceptance: > User can create a LuceneSerializer with the Java API and the LuceneSerializer > gets invoked. The documents returned by the LuceneSerializer are stored in > the index. > If objects are stored in the region as serialized PDX objects, they are > passed to the serializer as PdxInstance objects, rather than being > deserialized (Or should this be an option??) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3606) LuceneSerializer should take a LuceneIndex as a parameter
Dan Smith created GEODE-3606:
Summary: LuceneSerializer should take a LuceneIndex as a parameter
Key: GEODE-3606
URL: https://issues.apache.org/jira/browse/GEODE-3606
Project: Geode
Issue Type: Sub-task
Components: lucene
Reporter: Dan Smith
The LuceneSerializer API is currently specified as
{code}
LuceneSerializer {
Collection toDocuments(Object value);
}
{code}
Unfortunately, that means the serializer doesn't have access to the list of
fields and analyzers configured on the index. We should change the API to be
{code}
LuceneSerializer {
Collection toDocuments(LuceneIndex index, Object value);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (GEODE-3580) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan reassigned GEODE-3580:
---
Assignee: Galen O'Sullivan
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-3580
> URL: https://issues.apache.org/jira/browse/GEODE-3580
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Bruce Schuchardt
>Assignee: Galen O'Sullivan
>
> This test is failing because the PDX type registry doesn't have a PDX
> serializer but thinks that it should. When the PDX TypeRegistry is closed it
> leaves behind a static stating that it used to be open. This static isn't
> reset until a new cache is created but this test doesn't use a cache - only a
> DistributedSystem. When the deadlock detector executes its thread-state
> gathering function, which is Serializable, it hits code in
> InternalDataSerializer that looks for a PDXSerializer to handle the object
> and encounters this problem.
> I was going to just change the test to create a cache but I think it's
> possible that this same problem could arise in the context of auto-reconnect.
> Any attempt to serialize something during auto-reconnect that's not
> PDXSerializable, Sendable, DataSerializable or of a well known class could
> cause this same exception to be thrown.
> {noformat}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> java.lang.AssertionError: test is leaving behind an async invocation
> thread
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.waitForAsyncInvocation(GemFireDeadlockDetectorDUnitTest.java:213)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction(GemFireDeadlockDetectorDUnitTest.java:144)
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> org.apache.geode.cache.CacheClosedException: Could not PDX serialize
> because the cache was closed
> at
> org.apache.geode.pdx.internal.TypeRegistry.getPdxSerializer(TypeRegistry.java:331)
> at
> org.apache.geode.internal.InternalDataSerializer.writeUserObject(InternalDataSerializer.java:1536)
> at
> org.apache.geode.internal.InternalDataSerializer.writeWellKnownObject(InternalDataSerializer.java:1437)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2102)
> at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2936)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.toData(MemberFunctionStreamingMessage.java:308)
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2299)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1406)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:232)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:377)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:237)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:603)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1710)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1900)
> at
> org.apache.geode.distributed.internal.DistributionChannel.send(DistributionChannel.java:82)
> at
> org.apache.geode.distributed.internal.DistributionManager.sendOutgoing(DistributionManager.java:3463)
> at
> org.apache.geode.distributed.internal.DistributionManager.sendMessage(DistributionManager.java:3500)
> at
> org.apache.geode.distributed.internal.DistributionManager.putOutgoing(DistributionManager.java:1876)
> at
> org.apache.geode.internal.cache.execute.StreamingFunctionOperation.getFunctionResultFrom(StreamingFunctionOperation.java:108)
> at
> org.apache.geode.internal.cache.execute.MemberFunctionExecutor.executeFunction(MemberFunctionExecutor.java:155)
> at
> org.apache.geode.internal.cache.execute.MemberFunctionExecutor.executeFunction(MemberFunctionExecutor.java:201)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:395)
> at
>
[jira] [Created] (GEODE-3607) Be able to list my available backups via gfsh
Fred Krone created GEODE-3607: - Summary: Be able to list my available backups via gfsh Key: GEODE-3607 URL: https://issues.apache.org/jira/browse/GEODE-3607 Project: Geode Issue Type: Sub-task Components: regions Reporter: Fred Krone In another ticket there's a proposal to restore from a backup via a gfsh command. It would be great to be able to list the available backup files to restore from. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3608) Ability to set automatic scheduled backups
Fred Krone created GEODE-3608: - Summary: Ability to set automatic scheduled backups Key: GEODE-3608 URL: https://issues.apache.org/jira/browse/GEODE-3608 Project: Geode Issue Type: Sub-task Reporter: Fred Krone Yep -- this would be nice. Want to back up every 24 hours? Set it and forget it! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3240) User can set a LuceneSerializer through the Java API
[ https://issues.apache.org/jira/browse/GEODE-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163689#comment-16163689 ] ASF subversion and git services commented on GEODE-3240: Commit 6b5289f86d5d5da6af026fc520271cf96ff745ee in geode's branch refs/heads/feature/GEODE-3239 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6b5289f ] GEODE-3240: add implementation for java api of set serializer chnage createRepositoryManager's mapper to be LuceneSerializer add integration test This closes #770 > User can set a LuceneSerializer through the Java API > - > > Key: GEODE-3240 > URL: https://issues.apache.org/jira/browse/GEODE-3240 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Dan Smith > > As a user, I should be able to call LuceneIndexFactory.setLuceneSerializer > and pass my own LuceneSerializer when creating a lucene index. > The API for LuceneSerializer should be as specified on the wiki page. > Acceptance: > User can create a LuceneSerializer with the Java API and the LuceneSerializer > gets invoked. The documents returned by the LuceneSerializer are stored in > the index. > If objects are stored in the region as serialized PDX objects, they are > passed to the serializer as PdxInstance objects, rather than being > deserialized (Or should this be an option??) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3609) Cleanup AcceptorImpl use of ConnectionMode
Galen O'Sullivan created GEODE-3609: --- Summary: Cleanup AcceptorImpl use of ConnectionMode Key: GEODE-3609 URL: https://issues.apache.org/jira/browse/GEODE-3609 Project: Geode Issue Type: Improvement Components: messaging Reporter: Galen O'Sullivan AcceptorImpl currently uses three variables to keep track of the connection mode: a byte, a string, and a ConnectionMode (which can provide the byte and string). Change the implementation to just have the class. I have a PR for this, creating an issue to track it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (GEODE-3609) Cleanup AcceptorImpl use of ConnectionMode
[ https://issues.apache.org/jira/browse/GEODE-3609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-3609: --- Assignee: Galen O'Sullivan > Cleanup AcceptorImpl use of ConnectionMode > -- > > Key: GEODE-3609 > URL: https://issues.apache.org/jira/browse/GEODE-3609 > Project: Geode > Issue Type: Improvement > Components: messaging >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan > > AcceptorImpl currently uses three variables to keep track of the connection > mode: a byte, a string, and a ConnectionMode (which can provide the byte and > string). Change the implementation to just have the class. > I have a PR for this, creating an issue to track it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3563) SSL socket handling problems in TCPConduit run
[ https://issues.apache.org/jira/browse/GEODE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163144#comment-16163144 ] Vahram Aharonyan commented on GEODE-3563: - Hi Anthony, we don't have a pull request created for this ticket yet. We have some thoughts on this like : 1. putting timeout before configuring SSL socket as it was done in GEODE-2898, GEODE-3023 to avoid any blocking situation. 2. handle SSL exception and do some cleanup work to close the socket in run function. Does this seem to be reasonable? Thanks, Vahram. > SSL socket handling problems in TCPConduit run > -- > > Key: GEODE-3563 > URL: https://issues.apache.org/jira/browse/GEODE-3563 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Vahram Aharonyan > Fix For: 1.2.1 > > > Here are two cases that seems to problematic in TCPConduit.run flow: > 1. TCPConduit.run() has no action performed for the case when SSLException is > thrown from sslSocket.startHandshake(), as a result the socket remains open. > Catch block from the end of configureServerSSLSocket() will just report a > fatal error(even it seem that this portion is going to be removed in 1.2.1 > according to GEODE-3393) and re-throw the exception. > 2. configureServerSSLSocket call is performed without setting socket timeout > before that. This can bring to run thread blocking case if read initiated > from the SSL handshake flow will not return. Linking to similar issues > observed with other acceptors previously: GEODE-2898, GEODE-3023. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (GEODE-3563) SSL socket handling problems in TCPConduit run
[ https://issues.apache.org/jira/browse/GEODE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163144#comment-16163144 ] Vahram Aharonyan edited comment on GEODE-3563 at 9/12/17 3:46 PM: -- Hi [~amb], we don't have a pull request created for this ticket yet. We have some thoughts on this like : 1. putting timeout before configuring SSL socket as it was done in GEODE-2898, GEODE-3023 to avoid any blocking situation. 2. handle SSL exception and do some cleanup work to close the socket in run function. Does this seem to be reasonable? Thanks, Vahram. was (Author: vaharonyan): Hi Anthony, we don't have a pull request created for this ticket yet. We have some thoughts on this like : 1. putting timeout before configuring SSL socket as it was done in GEODE-2898, GEODE-3023 to avoid any blocking situation. 2. handle SSL exception and do some cleanup work to close the socket in run function. Does this seem to be reasonable? Thanks, Vahram. > SSL socket handling problems in TCPConduit run > -- > > Key: GEODE-3563 > URL: https://issues.apache.org/jira/browse/GEODE-3563 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Vahram Aharonyan > Fix For: 1.2.1 > > > Here are two cases that seems to problematic in TCPConduit.run flow: > 1. TCPConduit.run() has no action performed for the case when SSLException is > thrown from sslSocket.startHandshake(), as a result the socket remains open. > Catch block from the end of configureServerSSLSocket() will just report a > fatal error(even it seem that this portion is going to be removed in 1.2.1 > according to GEODE-3393) and re-throw the exception. > 2. configureServerSSLSocket call is performed without setting socket timeout > before that. This can bring to run thread blocking case if read initiated > from the SSL handshake flow will not return. Linking to similar issues > observed with other acceptors previously: GEODE-2898, GEODE-3023. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (GEODE-3603) Refactor exception handling in ProtoBuf operation handlers
Alexander Murmann created GEODE-3603: Summary: Refactor exception handling in ProtoBuf operation handlers Key: GEODE-3603 URL: https://issues.apache.org/jira/browse/GEODE-3603 Project: Geode Issue Type: Task Components: client/server Reporter: Alexander Murmann Introduce a shared means of handling exceptions by the operation handlers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (GEODE-3083) New protocol should record server statistics
[
https://issues.apache.org/jira/browse/GEODE-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163292#comment-16163292
]
ASF subversion and git services commented on GEODE-3083:
Commit 0c6f2ef55b50c20e7f5cbf63681836c15fb2d5c5 in geode's branch
refs/heads/feature/GEODE-3083 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0c6f2ef ]
GEODE-3083: New protocol should record statistics
wip
Statistics implemented: connections, connection starts, connection termination,
bytes/second received bytes/second sent
We need some performance testing on the byte measurement since it involves
traversing the Protobuf message objects to calculate their sizes.
We need additional stats including failed authentications/second and
failed authorization checks/second
> New protocol should record server statistics
>
>
> Key: GEODE-3083
> URL: https://issues.apache.org/jira/browse/GEODE-3083
> Project: Geode
> Issue Type: Sub-task
> Components: client/server
>Reporter: Galen O'Sullivan
>
> As a user of the new protocol, I need to be able to review accurate stats
> related to new protocol clients as well as any existing stats impacted by new
> clients (e.g., total client counts).
> Implement statistics for the new protocol, creating a new tree for
> new-protocol-specific stats, but also updating relevant existing stats:
> - client connections/threads
> - time to serve client requests
> - other stats impacted by new protocol clients that would be less helpful to
> end users/admins if new protocol neglected to increment/decrement
> Specifically, have a look at {{ServerConnection}} and see where it calls into
> its {{stats}} object. If these calls are applicable to us (at least some of
> them are), make the same calls.
>
> At a minimum, implement for new protocol clients:
> - Connection counts
> - Connection Starts/Stops
> - Bytes received/sent
> - Failed auth requests
> Document the statistics being captured for inclusion in the wiki.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GEODE-3587) Publish geode distribution as maven artifact
[
https://issues.apache.org/jira/browse/GEODE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16163298#comment-16163298
]
ASF subversion and git services commented on GEODE-3587:
Commit 52305a8a7679d761a084f866c1253777345fb29e in geode's branch
refs/heads/develop from [~amb]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=52305a8 ]
GEODE-3587 Fix the source distribution basename
> Publish geode distribution as maven artifact
>
>
> Key: GEODE-3587
> URL: https://issues.apache.org/jira/browse/GEODE-3587
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Jens Deppe
>Assignee: Jens Deppe
> Fix For: 1.3.0
>
>
> Some users would like to consume a full distribution as a maven artifact. We
> will publish the distribution as {{org.apache.geode:apache-geode:VERSION}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (GEODE-3526) Command 'alter runtime -- log-disk-space-limit' fails with null reason
[
https://issues.apache.org/jira/browse/GEODE-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-3526.
-
Resolution: Cannot Reproduce
I can't reproduce this now in my testing environment.
> Command 'alter runtime -- log-disk-space-limit' fails with null reason
> ---
>
> Key: GEODE-3526
> URL: https://issues.apache.org/jira/browse/GEODE-3526
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.2.0
>Reporter: Kenneth Howe
>
> Command response to the console is:
> {code}
> gfsh>alter runtime --log-disk-space-limit=1000
> Could not process command due to error. Error while processing command runtime --log-disk-space-limit=1000> Reason : null
> {code}
> The expected result should be something like:
> {code}
> gfsh>alter runtime --log-disk-space-limit=1000
> Runtime configuration altered successfully for the following member(s)
> 10.118.33.251(serv1:5078):1025
> {code}
> Investigation into this error has shown that the test coverage for
> {code}alter runtime{code} command is low. New tests are needed in this area.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
