+1
On Tue, Mar 12, 2019 at 5:32 PM John Blum wrote:
> Definitely a reasonable change. Perhaps, for consistency sake, the same
> should be applied to Geode's Memcached support? (in another PR).
>
>
> On Tue, Mar 12, 2019 at 4:23 PM Dan Smith wrote:
>
> > I created a PR to move our redis support
+1 to re-cut.
-Anil.
On Tue, Mar 19, 2019 at 2:11 PM Dick Cavender wrote:
> +1 to re-cutting the 1.9 release branch off a more stable develop sha
> within the last couple days.
>
> On Tue, Mar 19, 2019 at 1:14 PM Bruce Schuchardt
> wrote:
>
> > If we recut the release branch we need to update
+1. Will the expiration (destroy) be applied on local queues or the
expiration will be replicated (for both serial and parallel)?
-Anil.
On Wed, Mar 20, 2019 at 8:59 AM Bruce Schuchardt
wrote:
> We've seen situations where the receiving side of a WAN gateway is slow
> to accept data or is not
Yes. From our experiment that looked like a possibility.
-Anil.
On Tue, Mar 26, 2019 at 9:59 AM Dan Smith wrote:
> Following up on the conflation thing - Anil and I did an experiment.
> Conflation definitely *does* happen on everything in the queue, not just
> the last batch. But we didn't see
We should be supporting non-embedded mode; I believe most of the app-server
based use cases will be doing this. This also reduces the resource usage on
the geode cluster.
On Wed, May 1, 2019 at 10:44 AM Dan Smith wrote:
> Option 2 does sound like a good way to go. It does seem like if you are
>> around 5 hours, vs 2 hours for Linux tests).
May be a good time to look at reducing/optimizing this.
On Thu, May 16, 2019 at 9:57 AM Ernest Burghardt
wrote:
> Yes make them gating.
> Run them every commit, Windows is a supported platform.
> Red boxes get attention and Red boxes get fixed.
>
Make sense to me...Looking at the probability of breaking specific to, jdk8
and jdk11 through a commit.
On Wed, May 15, 2019 at 6:09 PM Owen Nichols wrote:
> Currently every PR commit triggers both JDK8 and JDK11 versions of each
> test job. I propose that we can eliminate the JDK8 version of
As this changes the behavior on the existing older application; it seems to
break the backward compatibility requirements.
We use client versions to keep the contracts/behavior same for older
client; can we do the same here.
-Anil.
On Thu, May 23, 2019 at 8:33 AM Darrel Schneider
wrote:
> Is i
that calling this method under these conditions had no value
> and would therefor never have been called then one could argue that
> implementing this method is adding a feature. It adds a case where one
> could legitimately call this method under new conditions.
>
> > On May 23, 2
Proposal to support controlling capability with event dispatch to
AsyncEventQueue Listener.
Wiki proposal page:
https://cwiki.apache.org/confluence/display/GEODE/%5BDraft%5D+Controlling+event+dispatch+to+AsyncEventListener
Here is the details from the wiki page:
*Problem*
*The Geode system requi
+1 to include
On Fri, Aug 16, 2019 at 2:41 PM Anthony Baker wrote:
> +1 from me. When you need to do an offline export, it’s usually
> important. Not being able to export *all* the data might lead to data loss.
>
> Anthony
>
>
> > On Aug 16, 2019, at 2:06 PM, Udo Kohlmeyer wrote:
> >
> > +1 t
ll pause
> on the AsyncEventQueue as soon as it is created? How would someone do that
> when creating AEQs with xml or cluster configuration? Maybe it would be
> better to not dispatch any events until we are done creating all regions?
>
> -Dan
>
> On Fri, Aug 16, 2019 at 2:31 PM Anil
I have updated the wiki based on Dan's comment.
Changes with api:
*On "AsyncEventQueueFactory" interface - *
*AsyncEventQueueFactory pauseEventDispatchToListener(); *// This causes
AEQ to be created with paused state.
On Fri, Aug 16, 2019 at 4:36 PM Anilkumar Gingade
wrote:
;
> > > Hello Anil,
> > >
> > > +1 for the proposed solution.
> > > I'd change the method name from *pauseEventDispatchToListener* to
> > something
> > > more meaningful and understandable for our users, maybe *startPaused*?,
> > > *setManualStart* (as w
My vote is for supporting all the region type currently supported. As mike
was pointing, we have seen usecases where different regions are used for
specific application needs.
On Tue, Aug 20, 2019 at 5:09 PM Darrel Schneider
wrote:
> gfsh create region currently does not support "distributed-n
Just to be clear between java and native-client api:
- Read timeout in function execution Java client API - This is to change
the java client behavior
And following are the native client problems and solution applies to
native-client?
- Timeout in ResultCollector::getResult() and Execution::execu
The use-cases I can think of are edge, mesh, IOT related, large scale
streaming services where data consistency or data loss (for sometime) is
not a concern; the edge/mesh computing are getting traction now a
dayGeode also supports early-ack option which gives better throughput
compare to distr
Its a good option. But do we see any use-cases, where user doesn't want to
wait for a server stop (if its taking long time) and continue to proceed
with other operation (say executing commands on other servers).
Also, i could not make out how this is related to GEODE-7017; the testcase
seems to be
+1. This is needed for spring data-geode; whose upcoming release is based
on older geode version.
-Anil.
On Fri, Sep 13, 2019 at 3:23 PM Nabarun Nag wrote:
> Hi Geode Community ,
>
> [GEODE-7121]
>
> I would like to include the new feature of creating AEQs with a paused
> event processor to th
Alberto,
Sorry for late responseCurrently geode (java client) does provide
ability to set function timeout; but its through internal system property
"gemfire.CLIENT_FUNCTION_TIMEOUT"Some of the tests using this property
are Tests extending "FunctionRetryTestBase".
Since this is through in
+1
On Thu, Sep 19, 2019 at 11:02 AM Eric Shu wrote:
> +1
>
>
> On Thu, Sep 19, 2019 at 10:59 AM Benjamin Ross wrote:
>
> > +1
> >
> > On Thu, Sep 19, 2019 at 10:50 AM Nabarun Nag wrote:
> >
> > > +1
> > >
> > > On Thu, Sep 19, 2019 at 10:49 AM Xiaojian Zhou
> wrote:
> > >
> > > > I want to me
Dan, Some reason, cant view the diagram...It doesn't show up...
On Thu, Sep 26, 2019 at 11:52 AM Dan Smith wrote:
> If you are wondering how this relates to the geode-log4j work that Kirk
> did, the following diagram might help. Basically, he made a geode-log4j
> module that makes log4j-core op
+1
On Fri, Oct 4, 2019 at 11:15 AM Juan José Ramos wrote:
> +1
>
>
>
>
> On Fri, Oct 4, 2019 at 6:39 PM Jens Deppe wrote:
>
> > On behalf of Juan I'm requesting approval to add GEODE-7079 to
> > release/1.9.2
> >
> > The original justification is:
> >
> > Long story short: GEODE-7079 can be hit
Looking at the code, the cache.close() and InternalCacheBuilder.create()
are synchronized on "GemFireCacheImpl.class"'; it's the
internalCachebuilder create that seems to be using reference to the old
distributed-system.
The GemFireCacheImpl.getInstance() and getExisting() both perform
"isClosing"
+1
On Tue, Nov 26, 2019 at 11:32 AM Udo Kohlmeyer wrote:
> This is no-brainer
>
> *+1*
>
> On 11/26/19 11:27 AM, Owen Nichols wrote:
> > I would like to propose bringing “GEODE-7465: Set eventProcessor to null
> in serial AEQ when it is stopped” into the 1.11 release (necessitating an
> RC4).
>
Trying to get a conclusion out of it:
- The SDG/STDG to address the issue by changing the code on its part
- Create JIRA ticket for the issue raised. And prioritize/work the issue in
coming GEODE release.
-Anil.
On Thu, Dec 5, 2019 at 10:12 AM Owen Nichols wrote:
> > On Dec 4, 2019, at 10:09 P
Alberto,
Can you please file a JIRA ticket for this. This could come up often as
more and more deployments move to K8s.
-Anil.
On Fri, Dec 6, 2019 at 8:33 AM Sai Boorlagadda
wrote:
> > if one gw receiver stops, the locator will publish to any remote locator
> that there are no receivers up.
>
I would like to keep as is...In my opinion this should not been seen as
policing; rather a concerted effort towards keeping the code stable. And
way to isolate the problem sooner than later (after merging of multiple
PRs, which will make it harder). Yes, I agree it may be annoying to sit on
code ch
+1 to include the performance benchmark code. It provides an
opportunity for community to use it and develop on it (a must needed when
Geode is termed as performant data product).
On Thu, Jan 16, 2020 at 6:35 PM Robert Houghton
wrote:
> Let's not vote until there is a call to vote, folks...
>
The stress test is to identify the flaky-ness within the test; and assuming
any changes to the test may have introduced the flaky-ness.
It's about paying the cost upfront or later when the test is determined to
be flaky.
If 25+ tests have been changed in a PR, the cost of running stress test for
th
Thanks Kirk. Can you add an example here...
On Wed, Mar 18, 2020 at 11:12 AM Kirk Lund wrote:
> Tips on using AsyncInvocation:
>
> * Always use await() or get()
> * Both check and throw any remote exceptions
> * Both use GeodeAwaitility Timeout and will throw TimeoutException if it’s
> exceeded
+1 The changes and the risk looks minimal.
On Thu, Mar 19, 2020 at 2:16 AM Alberto Bustamante Reyes
wrote:
> +1
>
> De: Donal Evans
> Enviado: jueves, 19 de marzo de 2020 2:14
> Para: dev@geode.apache.org
> Asunto: Re: [PROPOSAL]: Include GEODE-7832, GEODE-7853
+1
Based on: The risk is low. Avoids false positives in automated
vulnerability scans.
On Fri, Apr 10, 2020 at 12:33 PM Dick Cavender wrote:
> +1
>
> On Fri, Apr 10, 2020 at 11:16 AM Owen Nichols wrote:
>
> > Recently it’s been noticed that spring-core-5.2.1.RELEASE.jar is getting
> > flagged f
Yes, you can use partition resolver to achieve this.
You can also look into "StringPrefixPartitionResolver" which doesn't need
custom implementation.
https://geode.apache.org/docs/guide/111/developing/partitioned_regions/standard_custom_partitioning.html
-Anil
On Fri, Apr 10, 2020 at 11:08 AM st
Did you look into:"StringPrefixPartitionResolver" which doesn't need custom
implementation.
https://geode.apache.org/docs/guide/111/developing/partitioned_regions/standard_custom_partitioning.html
You can try key like - "key | file1"
-Anil.
On Fri, Apr 10, 2020 at 4:02 PM Dan Smith wrote:
> H
About api: I would not recommend using bucketId in api, as it is internal
and there are other internal/external apis that rely on bucket id
calculations; which could be compromised here.
Instead of adding new APIs, probably looking at minimizing/reducing the
time spent may be a good start.
Bucket
n peer nodes)..?
>
> Can someone explain about
> *PutAllPRMessage.operateOnPartitionedRegion(ClusterDistributionManager
> dm, PartitionedRegion pr,..)*, it seems this handles putAll msg from peer..
> When is this required..?
>
> Thanks
>
> Steve M.
>
> On Wed, Apr 15, 2020 at 11:06 PM Anilkumar Gin
Is there a better way to know if a member has left the distributed system,
than following:
I am checking using:
"partitionedRegion.getDistributionManager().isCurrentMember(requester));"
This returns true, even though the AdvisorListener on
ParitionedRegion already processed memberDeparted() event.
lying on callbacks.
>
> On Fri, Apr 17, 2020 at 3:03 PM Anilkumar Gingade
> wrote:
>
> > Is there a better way to know if a member has left the distributed
> system,
> > than following:
> > I am checking using:
> > "partitionedRegion.getDistributionManager()
Thanks Bruce.
Will take a look at "WaitForViewInstallation".
-Anil.
On Fri, Apr 17, 2020 at 3:44 PM Anilkumar Gingade
wrote:
> Thanks Kirk.
> This is for PR clear; I ended up registering/adding a new membership
> listener on DistributionManager (DM).
>
> I was tr
>> Rolling downgrade is a pretty important requirement for our customers
>> I'd love to hear what others think about whether this feature is worth
the overhead of making sure downgrades can always work.
I/We haven't seen users/customers requesting rolling downgrade as a
critical requirement for th
we
> ensure compatibility across the wan protocol.
>
> Is that correct?
>
>
> Anthony
>
>
>
> > On Apr 22, 2020, at 10:43 AM, Anilkumar Gingade
> wrote:
> >
> >>> Rolling downgrade is a pretty important requirement for our customers
> >>
Since this issue is introduced from 1.7; meaning its present from 1.7 time,
can it be added in the next release, is there any strong user/customer
requirement to get this in 1.13.
-Anil.
On Mon, May 4, 2020 at 11:55 AM Jinmei Liao wrote:
> I would like to include the fix for GEODE-8055 in the
+1
On Mon, May 11, 2020 at 4:10 PM Jinmei Liao wrote:
> https://issues.apache.org/jira/browse/GEODE-8091
>
> We've had users that were trying to use the
> "--load-cluster-configuration-from-dir=true" when starting up a locator
> with a security manager and came across this failure on Geode1.12 a
The Region separator should not be user visible. In the past, we had tried
to remove needing this from the end-user or any other place. If we look
into its usage, it is mostly for sub-regions and we don't recommend much
use of this.
I was also wondering, its use by external or management modules ha
Yes, the DLock machinery handles (has option) dlock grantor departure...
As I understand, right now we have dlock at config persistence layer, but this
does not guarantee preserving the order in which the config changes are
applied. E.g.: A create region command followed by destroy could be pers
Looking at the cost and value derived; My vote is with current/existing process
(not running for every PR).
On 6/25/20, 11:39 AM, "Mark Hanson" wrote:
I support adding it in, but I think the time wasted is less than you think.
I think for me the most important thing is finding an issue wh
+1 As Donal said, complete the feature with all the available APIs.
On 6/26/20, 11:50 AM, "Donal Evans" wrote:
+1
Although normally features wouldn't really count as "critical fixes" that
would warrant inclusion after the release branch has been cut, in this case,
the internal API an
It feels like, first, we should choose right resources/tools that is suited for
the task in hand and helps in achieving the expected result (Testing - easier
to develop, run, monitor and report); and then invest in that once. Even if it
means to add new tools/subroutines in the product.
E.g.:
B
Seems like a bug to me. Can you please create a jira ticket.
The active CQ counts will be more meaningful at member level; they could be
different on different servers based on the CQs registered and the redundancy
level set. And that helps to determine the load on each server.
-Anil.
On 7/1
Mario,
Here is how the CQ register behaves:
When there is a single client and two servers.
When CQ is registered, with redundancy 0:
- On non-partitioned region, the CQ gets registered on one server, through
registerCQ().
- On partitioned region, if the region is hosted on both server, the CQ ge
+1
This will provide a consistent experience our end user from 1.10 release
version.
On 7/22/20, 2:23 PM, "Jinmei Liao" wrote:
I would like to propose to cherry pick GEODE-8331: allow GFSH to connect to
other versions of cluster (#5375) to support branches up to 1.10. This would
allow g
This causes a large object to be partially (corrupt data) stored in cache
instead of throwing an exception.
+1 As it address a potential hang.
-Anil.
On 9/2/20, 10:38 AM, "Xiaojian Zhou" wrote:
Hi, All:
I want to backport my fix in GEODE-8475 to 1.13. It fixed a hang caused by
a potential deadlock.
This fix is quite safe, I have verified it by running all queue related
regression.
Amit,
You can find high level details at:
https://geode.apache.org/docs/guide/112/developing/storing_data_on_disk/chapter_overview.html
Geode keeps the Key always in memory. Geode creates different Region-Entries
(Key-Value pair) based on the region configuration and how/where data is
stored.
Are you seeing no-buckets for persistent regions or non-persistent. The buckets
are created dynamically; when data is added to corresponding buckets...
When server is restarted, in case of in-memory regions as the data is not
there, the bucket region may not have been created (my suspicion).
Can
the issue.
BR,
Mario
Šalje: Anilkumar Gingade
Poslano: 11. rujna 2020. 20:34
Prima: dev@geode.apache.org
Predmet: Re: Colocated regions missing some buckets after restart
Are you seeing no-buckets for persistent regions or non-
ate it a bit more.
BR,
Mario
________
Šalje: Anilkumar Gingade
Poslano: 15. rujna 2020. 16:36
Prima: dev@geode.apache.org
Predmet: Re: Colocated regions missing some buckets after restart
Mario,
I doubt this has anything to do with the cl
Dale, I have few questions that I have added as comments to the RFC.
On 10/6/20, 5:24 PM, "Jacob Barrett" wrote:
Do we expect this to be used by production code or just test code? If this
is going to be used by production code I am concerned with introducing another
singleton class into t
+1
On 10/8/20, 7:51 AM, "Jinmei Liao" wrote:
I would like to include the fix for GEODE-8574 to 1.13.1, it would greatly
help the Geode on k8s experience.
Thanks!
Jinmei
+1
After the PR pipeline is completed.
-Anil.
On 10/14/20, 1:32 PM, "Xiaojian Zhou" wrote:
Hi,
There’s a race that StateFlush could hang when the target member is
shutdown. GEODE-8608 fixed. This fix is a patch to GEODE-8385.
The fix should be backported to all previous version
+1
On 11/12/20, 11:34 AM, "Owen Nichols" wrote:
+1 Sounds good to me, thanks @Dick for stepping up!
Let's also start posting Geode release artifacts to GitHub too (as many
other projects already do). I've backfilled the last couple releases, check it
out here:
https://nam04.safelin
Gester, Looking at the sample query, I Believe Ankit is asking about OQL query
not Lucene...
-Anil.
On 11/23/20, 9:02 AM, "Xiaojian Zhou" wrote:
Ankit:
Geode provided lucene query on json field. Your query can be supported.
https://nam04.safelinks.protection.outlook.com/?url=h
Ankit,
Here is how you can query your JSON object.
String queryStr = "SELECT d.col1 FROM /JsonRegion v, v.data d where d.col1.k11
= 'aaa'";
As replied earlier; the data is stored as PdxInstance type in the cache. In the
PdxInstance, the data is stored as top level or nested collection of
obje
It will be really helpful if you share updated query.
Thanks
Ankit.
On Tue, Nov 24, 2020, 2:42 AM Anilkumar Gingade wrote:
> Ankit,
>
> Here is how you can query your JSON object.
>
> String queryStr = "SELECT d.col1 FROM /JsonRegion v, v.da
I was conversing with few of the dev's about requirement of different
settings/configuration for set of nodes in the cluster depending on the
business/application needs; for example set of nodes serving different kind of
application requirement (data store) than other nodes in the cluster
(comp
PROPOSAL] Change the default value of conserve-sockets to
false
+1 for having the default be conserve-sockets=false. Any time there has
been trouble and conserve-sockets=true is involved we always suggest changing
it to false.
On 12/3/20, 6:58 AM, "Anilkumar Gingade" wrote:
Gester, You mentioned 9.10; you mean 1.12 geode?
+1 for backporting.
-Anil.
On 12/3/20, 10:44 PM, "Xiaojian Zhou" wrote:
GEODE-8764 is an enhanced version of GEODE-6930.
Lucene functions should only require DATA:READ permission on the specified
region, no need to gain permission on
The doc you are pointing; tries to create region using Functions.
You can use the samples given there and modify as per your requirement or
create a new one.
Here is reference doc about function execution:
https://geode.apache.org/docs/guide/14/developing/function_exec/function_execution.html
Th
My recommendation will be:
- Identify, Prioritize, Merge 1.14 related work
- Stabilize. Cut the branch and Stabilize again (to test any new changes added
during first stabilize period)
-Anil.
On 12/18/20, 2:26 PM, "Mark Hanson" wrote:
I support the cut on a predetermined date. But I wil
Is there a user request to use this in an older version?
How easy is it to backport?
From the comments, it looks like it is needed for Geode artifacts published to
Maven? Is this true?
If there is no user request, and there is other way to include Tomcat session,
my view is to not backport, but
We are investigating GEODE-8671; while investigation is in progress we like to
treat this as a 1.14 blocker.
https://issues.apache.org/jira/browse/GEODE-8671
Thanks,
-Anil.
Bruce,
>> To solve that problem we currently have to issue a new 1.13 release that
>> knows about v1.12.1 and users have to roll their servers to the new v1.13.1.
Even if we introduce the client protocol version, the users still need to
upgrade to server version, that understands the protocol rig
Agree with Dan...
If we are trying to come-up with APIs that is useful for PCF, probably what
Wes has (wrapper around gfsh) approach may suffice...
As Dan was suggesting we should have generic approach (pcf and non-pcf
users); and many of the things can be accomplished by using existing
code-base
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58722/#review173010
---
Ship it!
Ship It!
- anilkumar gingade
On April 25, 2017, 10
.
Added new dunit test. Verified the failure without change.
precheckin in progress.
Thanks,
anilkumar gingade
The conservation on this thread is getting more focused on adopting JCache
(JSR107) standard...
Fred started this conversation to see if some of the admin APIs can be
supported as part of Java API, to help devs who wants to combine both admin
and business logic in the same application...
Currentl
---
Manual testing.
Running new unit test (added) with and without changes.
precheckin in progress.
Thanks,
anilkumar gingade
/diff/2/
Changes: https://reviews.apache.org/r/58813/diff/1-2/
Testing
---
Manual testing.
Running new unit test (added) with and without changes.
precheckin in progress.
Thanks,
anilkumar gingade
else part...Is this expected...
- anilkumar gingade
On April 28, 2017, 8:17 p.m., Eric Shu wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
.
Thanks,
anilkumar gingade
the same as the version tag.
Good catch...Added this new changes posted.
- anilkumar
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58813/#review173400
-------
-CREATION
Diff: https://reviews.apache.org/r/58813/diff/4/
Changes: https://reviews.apache.org/r/58813/diff/3-4/
Testing
---
Manual testing.
Running new unit test (added) with and without changes.
precheckin in progress.
Thanks,
anilkumar gingade
/DistributedRegionSearchLoadJUnitTest.java
PRE-CREATION
Diff: https://reviews.apache.org/r/58813/diff/5/
Changes: https://reviews.apache.org/r/58813/diff/4-5/
Testing
---
Manual testing.
Running new unit test (added) with and without changes.
precheckin in progress.
Thanks,
anilkumar gingade
/PersistentPartitionedRegionDUnitTest.java
ba3444c
geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/PersistentPartitionedRegionTestBase.java
ccdd38d
Diff: https://reviews.apache.org/r/59426/diff/1/
Testing
---
added new unit tests.
precheck started.
Thanks,
anilkumar gingade
9090>
It will be cleaner to have this in BucketRegion where the map is created.
getRemoteEventStates()
clearRemoteEventStates()
- anilkumar gingade
On May 19, 2017, 3:38 p.m., Eric Shu wrote:
>
> ---
> This is
Suranjan,
In your run, are you seeing GII failing on one server and then continuing
from another server?
Say there are 3 nodes in cluster. node1 and node2 with region r1
(exists)
- r1 is created on node3.
- node3 starts gii from node1 (gets disconnected in between).
- node3 starts gii from no
The spark has come a long way after 1.3...The connector needs to be
upgraded to be meaningful
+1 for A
The existing code could be used as a reference in the future...
-Anil.
On Wed, May 24, 2017 at 5:17 PM, Dan Smith wrote:
> Our geode-spark-connector needs some work. It's currently buildi
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60278/#review178577
---
Ship it!
Ship It!
- anilkumar gingade
On June 21, 2017, 5
/sockets/command/TXSynchronizationCommand.java
Lines 106 (patched)
<https://reviews.apache.org/r/60513/#comment253707>
Can we move this to doBeforeCompletion() as done in
createAfterCompletionRunnable() which returns the runnable.
- anilkumar gingade
On June 28, 2017, 6:58 p.m., Er
/ClientServerJTADUnitTest.java
Lines 107 (patched)
<https://reviews.apache.org/r/60808/#comment255437>
exceptionLogged?
- anilkumar gingade
On July 12, 2017, 5:12 p.m., Eric Shu wrote:
>
> ---
> This is an automatically gener
date the re under tx lock; if its not able to lock, then it
should have thrown tx conflict exception; or if its removed before taking the
lock, it should have thrown entry-not-found exception...
Now it looks like the invalidate returns true, even if the enty is not
invalidated.
- anilku
.java
45c6120
geode-core/src/test/java/org/apache/geode/pdx/PdxAttributesJUnitTest.java
ef15cd5
Diff: https://reviews.apache.org/r/60935/diff/1/
Testing
---
Added new test.
Precheckin started.
Thanks,
anilkumar gingade
5255b
geode-core/src/test/java/org/apache/geode/pdx/PdxAttributesJUnitTest.java
ef15cd5
Diff: https://reviews.apache.org/r/60935/diff/2/
Changes: https://reviews.apache.org/r/60935/diff/1-2/
Testing
---
Added new test.
Precheckin started.
Thanks,
anilkumar gingade
>> I also have a quick question about OQL -> how to get the most recent
update into a region having many updates? Is it something like:
You need to have timestamp associated with your entry/value; and use that
in your query to get the last update.
-Anil.
On Thu, Jul 27, 2017 at 9:34 AM, Rupert S
ion.catchException) that gives
a nice way to manage expected exceptions.
- anilkumar gingade
On Aug. 1, 2017, 9:41 p.m., Eric Shu wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http
/apache/geode/internal/cache/TXState.java
Lines 673 (patched)
<https://reviews.apache.org/r/61281/#comment257975>
For distTx we skip for taking locks on secondary.
- anilkumar gingade
On Aug. 2, 2017, 9:12 p.m., Eric Shu
You can find those in CqServiceImpl.process*()...
-Anil.
On Mon, Aug 7, 2017 at 9:14 AM, Roi Apelker wrote:
> Hello,
>
> I am trying to look into the code of the continuous query mechanism -
> where the GEODE server sends the notification back to the client.
>
> Can anyone point me to the cent
uld be most grateful :-)
>
> Thanks
>
> Roi
>
>
>
> -Original Message-
> From: Anilkumar Gingade [mailto:aging...@pivotal.io]
> Sent: Monday, August 07, 2017 8:23 PM
> To: dev@geode.apache.org
> Subject: Re: continuous query internal mechanism
>
> You
vents and CQ events?
>
> -Original Message-
> From: Anilkumar Gingade [mailto:aging...@pivotal.io]
> Sent: Monday, August 07, 2017 10:12 PM
> To: dev@geode.apache.org
> Subject: Re: continuous query internal mechanism
>
> CQ Processing on server side is same for all clients (Java, C
1 - 100 of 256 matches
Mail list logo
