Re: Need Help on understanding vsd files

2017-09-21 Thread Avinash Dongre 
>
> Hi All,
>
> I am looking at  getTime-PartitionedRegionStats using vsd tools. I need
> some help on how to interpret following graph.
> If there is a document which helps to explain please let me know.
>
>
> [image: Inline image 1]
>
>
> Thanks
> Avinash
>
>

Re: Need Help on understanding vsd files

2017-09-21 Thread Avinash Dongre 
Attaching the graph.

On Thu, Sep 21, 2017 at 2:45 PM, Avinash Dongre  wrote:

> Hi All,
>>
>> I am looking at  getTime-PartitionedRegionStats using vsd tools. I need
>> some help on how to interpret following graph.
>> If there is a document which helps to explain please let me know.
>>
>>
>> [image: Inline image 1]
>>
>>
>> Thanks
>> Avinash
>>
>>
>

Build failed in Jenkins: Geode-nightly #961

2017-09-21 Thread Apache Jenkins Server 
See 


Changes:

[abaker] Update version on release branch

[abaker] GEODE-2947: Error message is now specific to lucene indexes

[jiliao] GEODE-3006: reduce the frequency of ping request and reduce the 
loglevel

[jiliao] GEODE-2983: correctly handling --J option value that has "," inside.

[jstewart] GEODE-2989: Improve mechanism for scanning the classpath to find gfsh

[jstewart] GEODE-2966: RefactorLauncherLifecycleCommands

[jstewart] GEODE-2966: Restore command changes lost in merge conflict

[kmiller] GEODE-3014 Document server/region/Lucene index start-up sequence

[eshu] GEODE-2892: Add sizeOnServer and isEmptyOnServer to Region

[lgallinat] GEODE-2661: afterDestroy events fired on non-existent keys during

[kmiller] GEODE-2947: Document revised gfsh destroy error message

[dbarnes] GEODE-1672: When amount of overflowed persisted data exceeds heap size

[dbarnes] GEODE-1672: When amount of overflowed persisted data exceeds heap size

[jiliao] GEODE-2981: Fix the line feed code of the test expected value

[jiliao] GEODE-3033: Fixing NPE when jarFileNames is null in

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots This

[boglesby] GEODE-3040: Compare gateway profile order policy against 9.0 instead 
of

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots -

[dbarnes] GEODE-2555: Region Management docs page refers to the wrong field (id=

[abaker] GEODE-194: Remove spark connector

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots -

[dschneider] GEODE-3027: add a simple PartitionResolver

[jstewart] GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[dbarnes] GEODE-3029: Tomcat Install Documentation has incorrect required JARs

[jiliao] GEODE-2420: add file-size-limit param to the ExportLogsController

[klund] GEODE-2632: use immutable SecurityService impls to improve performance

[jiliao] GEODE-3054: escaping the escape character in the command string before

[klund] Revert "GEODE-2632: use immutable SecurityService impls to improve

[hkhamesra] Revert "GEODE-2804 Update InetSocketAddress, when there is 
IOException."

[nnag] GEODE-3025: Lucene queries are not allowed withing a transaction.

[dbarnes] GEODE-3044: User Manual: Update Swagger screen shots to match latest

[dbarnes] GEODE-2420: Warn a user if they try to export too much data, update 
gfsh

[kmiller] GEODE-3042: Quick doc of new string-based partition resolver

[huynhja] GEODE-3021: Any call after the first to setPdxStringFlag should no-op

[ukohlmeyer] GEODE-3065: Marking RedisServerTest.java as Flaky. Seemed to be 
failing

[dbarnes] Update geode-book README instructions

[abaker] GEODE-3023: TcpServer move soTimout for the socket for SSL Locators

[abaker] GEODE-3023: removing incorrect assertion

[abaker] Fix spotless failure

[jiliao] GEODE-2294: revert to avoid rest protocol change

[abaker] Update LICENSE after review

[abaker] GEODE-3024 race condition between server locator preparing membership

[abaker] GEODE-3024 race condition between server locator preparing membership

[eshu] GEODE-2301: Deprecate JTA transaction manager from Geode

[boglesby] GEODE-3072: Changed getMembershipId to use the client version

[abaker] Fix typo in dependency declaration from LICENSE review

[kmiller] GEODE-2301 Doc note to deprecate Geode JTA trans mgr

[boglesby] GEODE-3072: Ignore dunit test

[jiliao] GEODE-3092: fix specifiedDefaultValue for cacheLoader and cacheWriter

[jiliao] GEODE-3095: fix parameter type mismatch between the diskstore command

[jiliao] GEODE-3092: fix specifiedDefaultValue for cacheLoader and cacheWriter -

[bschuchardt] GEODE-3072: Events do not get removed from the client queue for 
1.0

[bschuchardt] GEODE-3139 remove current artifacts from classpath of

[boglesby] GEODE-3152: Changed to create a region name appropriate to the client

[bschuchardt] Revert "GEODE-3139 remove current artifacts from classpath of

[bschuchardt] GEODE-3139 remove artifacts from classpath of 
backward-compatibility

[upthewaterspout] GEODE-3139: Fixing compilation errors

[bschuchardt] Revert "Revert "GEODE-3139 remove current artifacts from 
classpath of

[hkhamesra] GEODE-3153 Client receives duplicate events during rolling upgrade

[hkhamesra] GEODE-3153 applied spotless

[upthewaterspout] GEODE-3172: Fix serialization errors copying queue between 
1.0 and 1.2

[bschuchardt] GEODE-3175 backward-compatibility tests fail with bad classpath

[abaker] bump version

[jstewart] GEODE-3313: Test utility supports building jar files with multiple

[jstewart] GEODE-3235: Deploy jar registers functions which extend 
FunctionAdapter

[abaker] GEODE-3393: One-way SSL commit failing with userHome/.keystore not

[abaker] GEODE-3314: Fix DLockService token leak.

[abaker] GEODE-3314 - Refactoring of DLockService to improve developer QoL. This

[abaker] GEODE-3410 Doc update for gfsh query comman

Build failed in Jenkins: Geode-nightly-flaky #128

2017-09-21 Thread Apache Jenkins Server 
See 


Changes:

[abaker] Update version on release branch

[abaker] GEODE-2947: Error message is now specific to lucene indexes

[jiliao] GEODE-3006: reduce the frequency of ping request and reduce the 
loglevel

[jiliao] GEODE-2983: correctly handling --J option value that has "," inside.

[jstewart] GEODE-2989: Improve mechanism for scanning the classpath to find gfsh

[jstewart] GEODE-2966: RefactorLauncherLifecycleCommands

[jstewart] GEODE-2966: Restore command changes lost in merge conflict

[kmiller] GEODE-3014 Document server/region/Lucene index start-up sequence

[eshu] GEODE-2892: Add sizeOnServer and isEmptyOnServer to Region

[lgallinat] GEODE-2661: afterDestroy events fired on non-existent keys during

[kmiller] GEODE-2947: Document revised gfsh destroy error message

[dbarnes] GEODE-1672: When amount of overflowed persisted data exceeds heap size

[dbarnes] GEODE-1672: When amount of overflowed persisted data exceeds heap size

[jiliao] GEODE-2981: Fix the line feed code of the test expected value

[jiliao] GEODE-3033: Fixing NPE when jarFileNames is null in

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots This

[boglesby] GEODE-3040: Compare gateway profile order policy against 9.0 instead 
of

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots -

[dbarnes] GEODE-2555: Region Management docs page refers to the wrong field (id=

[abaker] GEODE-194: Remove spark connector

[dbarnes] GEODE-3044: User Manual: Update Swagger example and screen shots -

[dschneider] GEODE-3027: add a simple PartitionResolver

[jstewart] GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[dbarnes] GEODE-3029: Tomcat Install Documentation has incorrect required JARs

[jiliao] GEODE-2420: add file-size-limit param to the ExportLogsController

[klund] GEODE-2632: use immutable SecurityService impls to improve performance

[jiliao] GEODE-3054: escaping the escape character in the command string before

[klund] Revert "GEODE-2632: use immutable SecurityService impls to improve

[hkhamesra] Revert "GEODE-2804 Update InetSocketAddress, when there is 
IOException."

[nnag] GEODE-3025: Lucene queries are not allowed withing a transaction.

[dbarnes] GEODE-3044: User Manual: Update Swagger screen shots to match latest

[dbarnes] GEODE-2420: Warn a user if they try to export too much data, update 
gfsh

[kmiller] GEODE-3042: Quick doc of new string-based partition resolver

[huynhja] GEODE-3021: Any call after the first to setPdxStringFlag should no-op

[ukohlmeyer] GEODE-3065: Marking RedisServerTest.java as Flaky. Seemed to be 
failing

[dbarnes] Update geode-book README instructions

[abaker] GEODE-3023: TcpServer move soTimout for the socket for SSL Locators

[abaker] GEODE-3023: removing incorrect assertion

[abaker] Fix spotless failure

[jiliao] GEODE-2294: revert to avoid rest protocol change

[abaker] Update LICENSE after review

[abaker] GEODE-3024 race condition between server locator preparing membership

[abaker] GEODE-3024 race condition between server locator preparing membership

[eshu] GEODE-2301: Deprecate JTA transaction manager from Geode

[boglesby] GEODE-3072: Changed getMembershipId to use the client version

[abaker] Fix typo in dependency declaration from LICENSE review

[kmiller] GEODE-2301 Doc note to deprecate Geode JTA trans mgr

[boglesby] GEODE-3072: Ignore dunit test

[jiliao] GEODE-3092: fix specifiedDefaultValue for cacheLoader and cacheWriter

[jiliao] GEODE-3095: fix parameter type mismatch between the diskstore command

[jiliao] GEODE-3092: fix specifiedDefaultValue for cacheLoader and cacheWriter -

[bschuchardt] GEODE-3072: Events do not get removed from the client queue for 
1.0

[bschuchardt] GEODE-3139 remove current artifacts from classpath of

[boglesby] GEODE-3152: Changed to create a region name appropriate to the client

[bschuchardt] Revert "GEODE-3139 remove current artifacts from classpath of

[bschuchardt] GEODE-3139 remove artifacts from classpath of 
backward-compatibility

[upthewaterspout] GEODE-3139: Fixing compilation errors

[bschuchardt] Revert "Revert "GEODE-3139 remove current artifacts from 
classpath of

[hkhamesra] GEODE-3153 Client receives duplicate events during rolling upgrade

[hkhamesra] GEODE-3153 applied spotless

[upthewaterspout] GEODE-3172: Fix serialization errors copying queue between 
1.0 and 1.2

[bschuchardt] GEODE-3175 backward-compatibility tests fail with bad classpath

[abaker] bump version

[jstewart] GEODE-3313: Test utility supports building jar files with multiple

[jstewart] GEODE-3235: Deploy jar registers functions which extend 
FunctionAdapter

[abaker] GEODE-3393: One-way SSL commit failing with userHome/.keystore not

[abaker] GEODE-3314: Fix DLockService token leak.

[abaker] GEODE-3314 - Refactoring of DLockService to improve developer QoL. This

[abaker] GEODE-3410 Doc update for gfsh query

[Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

2017-09-21 Thread Mark Hanson 
Hi All,

In reviewing the PdxWrapper class it, it seemed like it would be a good
move to make this a template class. This will allow better type checking
anytime we use it.

An example of what is being planned is to change from

MyClass object;
PdxWrapper((void *) object,...)
to PdxWrapper(object, )

I have a chunk of code moved over that seems to show it is possible, though
there are some bugs that need to be addressed, so it is not a done deal.

What do people think?

Thanks,
Mark

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

2017-09-21 Thread Mark Hanson 
Here is a link to my branch in my fork that has the changes on it.

https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper

Thanks,
Mark

On Thu, Sep 21, 2017 at 10:19 AM, Mark Hanson  wrote:

> Hi All,
>
> In reviewing the PdxWrapper class it, it seemed like it would be a good
> move to make this a template class. This will allow better type checking
> anytime we use it.
>
> An example of what is being planned is to change from
>
> MyClass object;
> PdxWrapper((void *) object,...)
> to PdxWrapper(object, )
>
> I have a chunk of code moved over that seems to show it is possible,
> though there are some bugs that need to be addressed, so it is not a done
> deal.
>
> What do people think?
>
> Thanks,
> Mark
>

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

2017-09-21 Thread Michael William Dodge 
+1 for type safety

Sarge

> On 21 Sep, 2017, at 10:21, Mark Hanson  wrote:
> 
> Here is a link to my branch in my fork that has the changes on it.
> 
> https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper
> 
> Thanks,
> Mark
> 
> On Thu, Sep 21, 2017 at 10:19 AM, Mark Hanson  wrote:
> 
>> Hi All,
>> 
>> In reviewing the PdxWrapper class it, it seemed like it would be a good
>> move to make this a template class. This will allow better type checking
>> anytime we use it.
>> 
>> An example of what is being planned is to change from
>> 
>> MyClass object;
>> PdxWrapper((void *) object,...)
>> to PdxWrapper(object, )
>> 
>> I have a chunk of code moved over that seems to show it is possible,
>> though there are some bugs that need to be addressed, so it is not a done
>> deal.
>> 
>> What do people think?
>> 
>> Thanks,
>> Mark
>>

Re: [DISCUSS] Addition of isValid API to Index interface

2017-09-21 Thread Dan Smith 
Scheduling an asynchronous task to drop the index everywhere seems like
it's adding a lot of complexity and potential for race conditions. Is it
really worth optimizing memory usage in this edge case where we hit an
exception updating an index? The objective of these changes is to fix a
window where we are leaving the system in a corrupt state, I think we
should do that in the least complicated way possible.

-Dan

On Wed, Sep 20, 2017 at 3:54 PM, Swapnil Bawaskar 
wrote:

> Thanks for the explanation Naba, please find my reply below:
> 1. Debugging: If we log a warning, that should get noticed immediately, so
> I don't think we need to worry about logs rolling.
> 2. Performance for a single put: We can always schedule an async task to
> drop the index.
>
> On Wed, Sep 20, 2017 at 3:49 PM Nabarun Nag  wrote:
>
> > Hi Swapnil,
> > There were few factors we considered before going with just invalidating
> > the index rather than destroying the index.
> > 1. Debugging reasons : If the indexes were destroyed and logs roll over,
> > and suddenly we see that indexes have disappeared, it will be tough to
> > differentiate between whether the indexes were created improperly in the
> > first place [/ restarts] or if a put corrupted it hence it was destroyed.
> > In case of marking it invalid, we know for sure that a put has corrupted
> > the index and prevent confusion for the user.
> >
> > 2. Performance perspective  : We were worried that if a put corrupts
> > multiple indexes and then that put is also responsible for destroying
> those
> > indexes may slow down the execution as it will have to acquire/release
> > locks to destroy indexes [especially in case of PR indexes]. We were also
> > worried about race conditions arising in that case.
> >
> > Regards
> > Nabarun
> >
> > On Wed, Sep 20, 2017 at 2:59 PM Swapnil Bawaskar 
> > wrote:
> >
> > > Sorry for not reading this thread earlier, but I was wondering what is
> > the
> > > point of just invalidating the index and having it lie around if it is
> > not
> > > going to be used?
> > > Can we just drop the index instead, and log a warning message to that
> > > effect? This will free up the memory used by the index and will
> > proactively
> > > let the admin/user know what happened.
> > >
> > > On Wed, Sep 20, 2017 at 9:59 AM Nabarun Nag  wrote:
> > >
> > > > The PR #768 has been created for this issue and also GEODE-3520 has
> > been
> > > > changed to reflect this requirement.
> > > >
> > > > Regards
> > > > Nabarun
> > > >
> > > > On Thu, Sep 14, 2017 at 5:29 PM Nabarun Nag  wrote:
> > > >
> > > > > Thanks you guys for the review. I will revert the GEODE-3520 ticket
> > to
> > > > > reflect that invalidate should happen for both synchronous and
> > > > asynchronous
> > > > > index maintenance.
> > > > > Also, I will resend the PR which reflects the changes mentioned in
> > the
> > > > > ticket
> > > > >
> > > > > Regards
> > > > > Nabarun Nag
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Sep 14, 2017 at 5:55 PM Anilkumar Gingade <
> > aging...@pivotal.io
> > > >
> > > > > wrote:
> > > > >
> > > > >> Dan, you are right...Thanks to Jason, myself and Jason looked into
> > the
> > > > >> code
> > > > >> to see if index is updated before the event/change is
> saved/injected
> > > > into
> > > > >> the region...It looks like the index update are happening after
> the
> > > > region
> > > > >> change/update is saved. Moving the index update before that is not
> > an
> > > > easy
> > > > >> task...
> > > > >>
> > > > >> For time, when there is any problem with index update, we can
> > proceed
> > > > with
> > > > >> invalidating the indexes...But we really need to look at making
> > region
> > > > and
> > > > >> index updates in a transactional way, silently invalidating
> indexes
> > > may
> > > > >> not
> > > > >> be acceptable...
> > > > >>
> > > > >> -Anil.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Thu, Sep 14, 2017 at 1:12 PM, Dan Smith 
> > wrote:
> > > > >>
> > > > >> > I'm still going to push that we stick with Naba's original
> > proposal.
> > > > >> >
> > > > >> > The current behavior is clearly broken. If one index update
> fails,
> > > an
> > > > >> > exception gets thrown to the user (nice!) but it leaves the put
> > in a
> > > > >> > partially completed state - some other indexes may not have been
> > > > >> updated,
> > > > >> > WAN/AEQs may not have been notified, etc.
> > > > >> >
> > > > >> > We should never leave the system in this corrupted state. It
> would
> > > be
> > > > >> nice
> > > > >> > to be able to cleanly rollback the put, but we don't have that
> > > > >> capability
> > > > >> > especially considering that cache writers have already been
> > invoked.
> > > > So
> > > > >> the
> > > > >> > next best thing is to invalidate the index that failed to
> update.
> > > > >> >
> > > > >> > Logging an error an allowing the put to succeed does match what
> we
> > > do
> > > > >> with
> > > > >> > CacheListen

Re: Need Help on understanding vsd files

2017-09-21 Thread Anilkumar Gingade 
At a high level, you can find stat descriptions by "selecting a stat" and
then clicking (in vsd) main->"Show Statistic Info".

-Anil.


On Thu, Sep 21, 2017 at 2:24 AM, Avinash Dongre  wrote:

> Attaching the graph.
>
> On Thu, Sep 21, 2017 at 2:45 PM, Avinash Dongre 
> wrote:
>
>> Hi All,
>>>
>>> I am looking at  getTime-PartitionedRegionStats using vsd tools. I need
>>> some help on how to interpret following graph.
>>> If there is a document which helps to explain please let me know.
>>>
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> Thanks
>>> Avinash
>>>
>>>
>>
>

Re: [DISCUSS] Addition of isValid API to Index interface

2017-09-21 Thread Jason Huynh 
I agree with Dan and Naba.  The possible race conditions seem very risky to
me.  Memory optimization isn't really needed here because the user has
already budgeted memory for the index.  They probably weren't trying to
create an index that would be corrupted and when it does get corrupted, it
won't take any more memory than they had originally expected from an index.



On Thu, Sep 21, 2017 at 10:25 AM Dan Smith  wrote:

> Scheduling an asynchronous task to drop the index everywhere seems like
> it's adding a lot of complexity and potential for race conditions. Is it
> really worth optimizing memory usage in this edge case where we hit an
> exception updating an index? The objective of these changes is to fix a
> window where we are leaving the system in a corrupt state, I think we
> should do that in the least complicated way possible.
>
> -Dan
>
> On Wed, Sep 20, 2017 at 3:54 PM, Swapnil Bawaskar 
> wrote:
>
> > Thanks for the explanation Naba, please find my reply below:
> > 1. Debugging: If we log a warning, that should get noticed immediately,
> so
> > I don't think we need to worry about logs rolling.
> > 2. Performance for a single put: We can always schedule an async task to
> > drop the index.
> >
> > On Wed, Sep 20, 2017 at 3:49 PM Nabarun Nag  wrote:
> >
> > > Hi Swapnil,
> > > There were few factors we considered before going with just
> invalidating
> > > the index rather than destroying the index.
> > > 1. Debugging reasons : If the indexes were destroyed and logs roll
> over,
> > > and suddenly we see that indexes have disappeared, it will be tough to
> > > differentiate between whether the indexes were created improperly in
> the
> > > first place [/ restarts] or if a put corrupted it hence it was
> destroyed.
> > > In case of marking it invalid, we know for sure that a put has
> corrupted
> > > the index and prevent confusion for the user.
> > >
> > > 2. Performance perspective  : We were worried that if a put corrupts
> > > multiple indexes and then that put is also responsible for destroying
> > those
> > > indexes may slow down the execution as it will have to acquire/release
> > > locks to destroy indexes [especially in case of PR indexes]. We were
> also
> > > worried about race conditions arising in that case.
> > >
> > > Regards
> > > Nabarun
> > >
> > > On Wed, Sep 20, 2017 at 2:59 PM Swapnil Bawaskar  >
> > > wrote:
> > >
> > > > Sorry for not reading this thread earlier, but I was wondering what
> is
> > > the
> > > > point of just invalidating the index and having it lie around if it
> is
> > > not
> > > > going to be used?
> > > > Can we just drop the index instead, and log a warning message to that
> > > > effect? This will free up the memory used by the index and will
> > > proactively
> > > > let the admin/user know what happened.
> > > >
> > > > On Wed, Sep 20, 2017 at 9:59 AM Nabarun Nag  wrote:
> > > >
> > > > > The PR #768 has been created for this issue and also GEODE-3520 has
> > > been
> > > > > changed to reflect this requirement.
> > > > >
> > > > > Regards
> > > > > Nabarun
> > > > >
> > > > > On Thu, Sep 14, 2017 at 5:29 PM Nabarun Nag 
> wrote:
> > > > >
> > > > > > Thanks you guys for the review. I will revert the GEODE-3520
> ticket
> > > to
> > > > > > reflect that invalidate should happen for both synchronous and
> > > > > asynchronous
> > > > > > index maintenance.
> > > > > > Also, I will resend the PR which reflects the changes mentioned
> in
> > > the
> > > > > > ticket
> > > > > >
> > > > > > Regards
> > > > > > Nabarun Nag
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 14, 2017 at 5:55 PM Anilkumar Gingade <
> > > aging...@pivotal.io
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Dan, you are right...Thanks to Jason, myself and Jason looked
> into
> > > the
> > > > > >> code
> > > > > >> to see if index is updated before the event/change is
> > saved/injected
> > > > > into
> > > > > >> the region...It looks like the index update are happening after
> > the
> > > > > region
> > > > > >> change/update is saved. Moving the index update before that is
> not
> > > an
> > > > > easy
> > > > > >> task...
> > > > > >>
> > > > > >> For time, when there is any problem with index update, we can
> > > proceed
> > > > > with
> > > > > >> invalidating the indexes...But we really need to look at making
> > > region
> > > > > and
> > > > > >> index updates in a transactional way, silently invalidating
> > indexes
> > > > may
> > > > > >> not
> > > > > >> be acceptable...
> > > > > >>
> > > > > >> -Anil.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On Thu, Sep 14, 2017 at 1:12 PM, Dan Smith 
> > > wrote:
> > > > > >>
> > > > > >> > I'm still going to push that we stick with Naba's original
> > > proposal.
> > > > > >> >
> > > > > >> > The current behavior is clearly broken. If one index update
> > fails,
> > > > an
> > > > > >> > exception gets thrown to the user (nice!) but it leaves the
> put
> > > in a

Re: New client/server protocol - seeking feedback

2017-09-21 Thread Dan Smith 
I'm curious about few things I see in the .proto files.

1) I see there is a correlationId in the MessageHeader definition. What is
that used for? I remember we had a discussion a while back where I thought
we had decided that might not be not necessary?

2) I also see a CreateRegionRequest and DestroyRegionRequest in the .proto
files. Are those actually going to be part of the 1.0 GA? Should these be
removed?

3) The GetRegion command seems like it is returning either too much
information or to little. It returns some of the attributes of the region,
like data policy, scope, whether it's persistent (duplicate of data
policy?). What is this command for, and should it really be returning this
information which seems irrelevant to the client?

4) For GetAll, PutAll, the old client server protocol did not return the
keys in the response, it just sent back the results in the same order as
the request. This saves some data on the wire. I"m not sure if it's worth
complexity for this new protocol or not.

Looking forward to seeing some more information about how to actually use
these messages to communicate with a server - IE what type of connection
should I create, how SSL works, how authentication works, etc.

-Dan

On Fri, Sep 15, 2017 at 5:50 PM, Brian Baynes  wrote:

> You can find them in the code, but we'll be providing better documentation
> on the messages shortly. The proto files have the message definitions and
> they're pretty straightforward, but we'll have a more user-friendly
> write-up soon.
>
>
> On Sep 15, 2017 5:27 PM, "Dan Smith"  wrote:
>
> What's the best place to look for more details on the specific protocol for
> the v1.0 messages? The other pages on https://cwiki.apache.org/
> confluence/display/GEODE/New+Client+Server+Protocol? Or directly in the
> code somewhere?
>
> -Dan
>
> On Fri, Sep 15, 2017 at 11:15 AM, Brian Baynes  wrote:
>
> > Greetings, friends of Geode.
> >
> > Work has been progressing on the new client/server protocol for Geode and
> > we're approaching a GA v1.0.  Completed work/features include put/get,
> > putAll, getAll, remove, one-way SSL, authentication and authorization,
> and
> > support for primitive types and JSON documents as values (saved in PDX on
> > the server).
> >
> > Invite you to review the road map toward GA v1.0, the features proposed
> for
> > post-v1.0, and give us your feedback!  (Directly in Confluence or here on
> > dev@geode.apache.org)
> >
> > New Client/Server Protocol - Road Map, Proposed
> > 
> >
> >
> > Thanks for your input,
> >
> > Brian
> >
>

Re: [DISCUSS] Addition of isValid API to Index interface

2017-09-21 Thread Swapnil Bawaskar 
Can anyone help me understand the race condition?
My understanding was that in addition to setting the isInvalid flag, we
fire off a background task to drop the index. This task can use the
plumbing that gfsh uses to drop the index. Even if we schedule more than
one of these tasks, the later tasks would become no-op.
In my opinion we should do this optimization now, but if others disagree, I
will file an improvement jira.


On Thu, Sep 21, 2017 at 10:45 AM Jason Huynh  wrote:

> I agree with Dan and Naba.  The possible race conditions seem very risky to
> me.  Memory optimization isn't really needed here because the user has
> already budgeted memory for the index.  They probably weren't trying to
> create an index that would be corrupted and when it does get corrupted, it
> won't take any more memory than they had originally expected from an index.
>
>
>
> On Thu, Sep 21, 2017 at 10:25 AM Dan Smith  wrote:
>
> > Scheduling an asynchronous task to drop the index everywhere seems like
> > it's adding a lot of complexity and potential for race conditions. Is it
> > really worth optimizing memory usage in this edge case where we hit an
> > exception updating an index? The objective of these changes is to fix a
> > window where we are leaving the system in a corrupt state, I think we
> > should do that in the least complicated way possible.
> >
> > -Dan
> >
> > On Wed, Sep 20, 2017 at 3:54 PM, Swapnil Bawaskar 
> > wrote:
> >
> > > Thanks for the explanation Naba, please find my reply below:
> > > 1. Debugging: If we log a warning, that should get noticed immediately,
> > so
> > > I don't think we need to worry about logs rolling.
> > > 2. Performance for a single put: We can always schedule an async task
> to
> > > drop the index.
> > >
> > > On Wed, Sep 20, 2017 at 3:49 PM Nabarun Nag  wrote:
> > >
> > > > Hi Swapnil,
> > > > There were few factors we considered before going with just
> > invalidating
> > > > the index rather than destroying the index.
> > > > 1. Debugging reasons : If the indexes were destroyed and logs roll
> > over,
> > > > and suddenly we see that indexes have disappeared, it will be tough
> to
> > > > differentiate between whether the indexes were created improperly in
> > the
> > > > first place [/ restarts] or if a put corrupted it hence it was
> > destroyed.
> > > > In case of marking it invalid, we know for sure that a put has
> > corrupted
> > > > the index and prevent confusion for the user.
> > > >
> > > > 2. Performance perspective  : We were worried that if a put corrupts
> > > > multiple indexes and then that put is also responsible for destroying
> > > those
> > > > indexes may slow down the execution as it will have to
> acquire/release
> > > > locks to destroy indexes [especially in case of PR indexes]. We were
> > also
> > > > worried about race conditions arising in that case.
> > > >
> > > > Regards
> > > > Nabarun
> > > >
> > > > On Wed, Sep 20, 2017 at 2:59 PM Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > Sorry for not reading this thread earlier, but I was wondering what
> > is
> > > > the
> > > > > point of just invalidating the index and having it lie around if it
> > is
> > > > not
> > > > > going to be used?
> > > > > Can we just drop the index instead, and log a warning message to
> that
> > > > > effect? This will free up the memory used by the index and will
> > > > proactively
> > > > > let the admin/user know what happened.
> > > > >
> > > > > On Wed, Sep 20, 2017 at 9:59 AM Nabarun Nag 
> wrote:
> > > > >
> > > > > > The PR #768 has been created for this issue and also GEODE-3520
> has
> > > > been
> > > > > > changed to reflect this requirement.
> > > > > >
> > > > > > Regards
> > > > > > Nabarun
> > > > > >
> > > > > > On Thu, Sep 14, 2017 at 5:29 PM Nabarun Nag 
> > wrote:
> > > > > >
> > > > > > > Thanks you guys for the review. I will revert the GEODE-3520
> > ticket
> > > > to
> > > > > > > reflect that invalidate should happen for both synchronous and
> > > > > > asynchronous
> > > > > > > index maintenance.
> > > > > > > Also, I will resend the PR which reflects the changes mentioned
> > in
> > > > the
> > > > > > > ticket
> > > > > > >
> > > > > > > Regards
> > > > > > > Nabarun Nag
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Sep 14, 2017 at 5:55 PM Anilkumar Gingade <
> > > > aging...@pivotal.io
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Dan, you are right...Thanks to Jason, myself and Jason looked
> > into
> > > > the
> > > > > > >> code
> > > > > > >> to see if index is updated before the event/change is
> > > saved/injected
> > > > > > into
> > > > > > >> the region...It looks like the index update are happening
> after
> > > the
> > > > > > region
> > > > > > >> change/update is saved. Moving the index update before that is
> > not
> > > > an
> > > > > > easy
> > > > > > >> task...
> > > > > > >>
> > > > > > >> For time, when there is any probl

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

2017-09-21 Thread David Kimura 
Is using PdxWrapper any different than if user added their type into the
serialization registry?  If not, then do we really want to provide 2 ways
to do the same thing?

Thanks,
David

On Thu, Sep 21, 2017 at 10:24 AM, Michael William Dodge 
wrote:

> +1 for type safety
>
> Sarge
>
> > On 21 Sep, 2017, at 10:21, Mark Hanson  wrote:
> >
> > Here is a link to my branch in my fork that has the changes on it.
> >
> > https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper
> >
> > Thanks,
> > Mark
> >
> > On Thu, Sep 21, 2017 at 10:19 AM, Mark Hanson 
> wrote:
> >
> >> Hi All,
> >>
> >> In reviewing the PdxWrapper class it, it seemed like it would be a good
> >> move to make this a template class. This will allow better type checking
> >> anytime we use it.
> >>
> >> An example of what is being planned is to change from
> >>
> >> MyClass object;
> >> PdxWrapper((void *) object,...)
> >> to PdxWrapper(object, )
> >>
> >> I have a chunk of code moved over that seems to show it is possible,
> >> though there are some bugs that need to be addressed, so it is not a
> done
> >> deal.
> >>
> >> What do people think?
> >>
> >> Thanks,
> >> Mark
> >>
>
>

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

2017-09-21 Thread Jacob Barrett 
It may be work looking into the documentation a little to understand the
purpose of the PdxWrapper.

On Thu, Sep 21, 2017 at 11:37 AM David Kimura  wrote:

> Is using PdxWrapper any different than if user added their type into the
> serialization registry?  If not, then do we really want to provide 2 ways
> to do the same thing?
>
> Thanks,
> David
>
> On Thu, Sep 21, 2017 at 10:24 AM, Michael William Dodge  >
> wrote:
>
> > +1 for type safety
> >
> > Sarge
> >
> > > On 21 Sep, 2017, at 10:21, Mark Hanson  wrote:
> > >
> > > Here is a link to my branch in my fork that has the changes on it.
> > >
> > > https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper
> > >
> > > Thanks,
> > > Mark
> > >
> > > On Thu, Sep 21, 2017 at 10:19 AM, Mark Hanson 
> > wrote:
> > >
> > >> Hi All,
> > >>
> > >> In reviewing the PdxWrapper class it, it seemed like it would be a
> good
> > >> move to make this a template class. This will allow better type
> checking
> > >> anytime we use it.
> > >>
> > >> An example of what is being planned is to change from
> > >>
> > >> MyClass object;
> > >> PdxWrapper((void *) object,...)
> > >> to PdxWrapper(object, )
> > >>
> > >> I have a chunk of code moved over that seems to show it is possible,
> > >> though there are some bugs that need to be addressed, so it is not a
> > done
> > >> deal.
> > >>
> > >> What do people think?
> > >>
> > >> Thanks,
> > >> Mark
> > >>
> >
> >
>

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

2017-09-21 Thread David Kimura 
I briefly scanned some docs, but I'm still not sure I follow why this needs
to be in our domain.  It says PdxWrapper is "for domain objects that you
cannot or do not want to modify".

Why can't the application create an opaque wrapper around the object that
cannot be modified and register that wrapper with the serialization
registry - just like other serializable classes without us being the wiser
that it is a wrapper?

Thanks,
David

On Thu, Sep 21, 2017 at 11:49 AM, Jacob Barrett  wrote:

> It may be work looking into the documentation a little to understand the
> purpose of the PdxWrapper.
>
> On Thu, Sep 21, 2017 at 11:37 AM David Kimura  wrote:
>
> > Is using PdxWrapper any different than if user added their type into the
> > serialization registry?  If not, then do we really want to provide 2 ways
> > to do the same thing?
> >
> > Thanks,
> > David
> >
> > On Thu, Sep 21, 2017 at 10:24 AM, Michael William Dodge <
> mdo...@pivotal.io
> > >
> > wrote:
> >
> > > +1 for type safety
> > >
> > > Sarge
> > >
> > > > On 21 Sep, 2017, at 10:21, Mark Hanson  wrote:
> > > >
> > > > Here is a link to my branch in my fork that has the changes on it.
> > > >
> > > > https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper
> > > >
> > > > Thanks,
> > > > Mark
> > > >
> > > > On Thu, Sep 21, 2017 at 10:19 AM, Mark Hanson 
> > > wrote:
> > > >
> > > >> Hi All,
> > > >>
> > > >> In reviewing the PdxWrapper class it, it seemed like it would be a
> > good
> > > >> move to make this a template class. This will allow better type
> > checking
> > > >> anytime we use it.
> > > >>
> > > >> An example of what is being planned is to change from
> > > >>
> > > >> MyClass object;
> > > >> PdxWrapper((void *) object,...)
> > > >> to PdxWrapper(object, )
> > > >>
> > > >> I have a chunk of code moved over that seems to show it is possible,
> > > >> though there are some bugs that need to be addressed, so it is not a
> > > done
> > > >> deal.
> > > >>
> > > >> What do people think?
> > > >>
> > > >> Thanks,
> > > >> Mark
> > > >>
> > >
> > >
> >
>

[ANNOUNCE] Apache Geode 1.2.1

2017-09-21 Thread Anthony Baker 
The Apache Geode community is pleased to announce the availability of
Apache Geode 1.2.1.

Apache Geode is a data management platform that provides a
database-like consistency model, reliable transaction processing and a
shared-nothing architecture to maintain very low latency performance
with high concurrency processing.

Geode 1.2.1 is a patch release containing a small number of
improvements and bug fixes.  These fixes include improvements in
one-way SSL support, gfsh queries, code deployment, and validation of
internal client/server messages.  Users are encouraged to upgrade to
the latest release.

For the full list of changes please review the release notes:
  
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.2.1

The release artifacts can be downloaded from the project website:
  http://geode.apache.org/releases/

The release documentation is available at:
  http://geode.apache.org/docs/guide/latest/about_geode.html

We would like to thank all the contributors that made the release possible.

Regards,
Anthony Baker on behalf of the Apache Geode team

Re: Need Help on understanding vsd files

2017-09-21 Thread Barry Oglesby 
You probably need more than just the getTime stat to see whats going on
there. That stat is basically telling you how much time per second get
operations are occurring. You probably need to also know how many gets are
occurring.

What I generally do is:

- plot time stat (getTime in this case)
- divide time stat by 100 to get milliseconds (top right in vsd)
- plot operation stat (getsCompleted in this case)
- change both to 'No Filter' (top right drop down in vsd). This tells you
total time and number of operations.
- Divide time stat by operations stat to get average time per operation.
You can do this with either vsd or a calculator. I generally use a
calculator and divide the maximum of each stat, but with vsd:
  - select time stat line
  - select 'Line' -> 'Divide Lines' menu option
  - select operation stat line
  - the last sample of the resulting line is the average for the entire run

I attached charts for each step.


Thanks,
Barry Oglesby


On Thu, Sep 21, 2017 at 10:29 AM, Anilkumar Gingade 
wrote:

> At a high level, you can find stat descriptions by "selecting a stat" and
> then clicking (in vsd) main->"Show Statistic Info".
>
> -Anil.
>
>
> On Thu, Sep 21, 2017 at 2:24 AM, Avinash Dongre 
> wrote:
>
>> Attaching the graph.
>>
>> On Thu, Sep 21, 2017 at 2:45 PM, Avinash Dongre 
>> wrote:
>>
>>> Hi All,

 I am looking at  getTime-PartitionedRegionStats using vsd tools. I
 need some help on how to interpret following graph.
 If there is a document which helps to explain please let me know.


 [image: Inline image 1]


 Thanks
 Avinash


>>>
>>
>

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

2017-09-21 Thread Jacob Barrett 
As it stands right now this object has some funkiness that makes there
tricky I think. It might be worth leaving it alone actually and deprecating
it for something different.

class MyUnmodifiedClass;

class MyUnmodifiedClassPdxSerializer : PdxSerializer {
  using PdxSerializer::PdxSerializer;
  MyUnmodifiedClassPdxSerializer* createDeserializable() const override {
return MyUnmodifiedClass();
  }
}

using MyPdxType = PdxWrapper;

void func() {
  ...
  serializationRegistry->addPdxType(MyPdxType::createDeserializable);
  auto value = std::dynamic_pointer_cast(region.get("key"));
  auto /*MyUnmodifiedClass*/ unwrappedValue = value->getValue();
  ...
}

Probably even something nicer than this even?


That said, is the wrapper serving anything, how about this?

class MyUnmodifiedClassPdxSerializer : PdxSerializer {
  using PdxSerializer::PdxSerializer;

  const std::string& getClassName() const override {
constexp std::string("MyUnmodifiedClass");
  }

  std::shared_ptr fromData(PdxReader& reader) const
override {
auto a = reader.readInt("a");
auto b = reader.readDouble("b");
return std::make_shared(a, b); // Takes care of
deleter issues.
  }

  void toData(PdxWriter& writer, const MyUnmodifiedClass& obj) const
override {
writer.writeInt("a", obj.getA());
writer.writeDouble("b", obj.getB());
  }

}

serializationRegistry->addPdxSerializer(MyUnmodifiedClassPdxSerializer());


-Jake



On Thu, Sep 21, 2017 at 12:06 PM David Kimura  wrote:

> I briefly scanned some docs, but I'm still not sure I follow why this needs
> to be in our domain.  It says PdxWrapper is "for domain objects that you
> cannot or do not want to modify".
>
> Why can't the application create an opaque wrapper around the object that
> cannot be modified and register that wrapper with the serialization
> registry - just like other serializable classes without us being the wiser
> that it is a wrapper?
>
> Thanks,
> David
>
> On Thu, Sep 21, 2017 at 11:49 AM, Jacob Barrett 
> wrote:
>
> > It may be work looking into the documentation a little to understand the
> > purpose of the PdxWrapper.
> >
> > On Thu, Sep 21, 2017 at 11:37 AM David Kimura 
> wrote:
> >
> > > Is using PdxWrapper any different than if user added their type into
> the
> > > serialization registry?  If not, then do we really want to provide 2
> ways
> > > to do the same thing?
> > >
> > > Thanks,
> > > David
> > >
> > > On Thu, Sep 21, 2017 at 10:24 AM, Michael William Dodge <
> > mdo...@pivotal.io
> > > >
> > > wrote:
> > >
> > > > +1 for type safety
> > > >
> > > > Sarge
> > > >
> > > > > On 21 Sep, 2017, at 10:21, Mark Hanson  wrote:
> > > > >
> > > > > Here is a link to my branch in my fork that has the changes on it.
> > > > >
> > > > >
> https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper
> > > > >
> > > > > Thanks,
> > > > > Mark
> > > > >
> > > > > On Thu, Sep 21, 2017 at 10:19 AM, Mark Hanson 
> > > > wrote:
> > > > >
> > > > >> Hi All,
> > > > >>
> > > > >> In reviewing the PdxWrapper class it, it seemed like it would be a
> > > good
> > > > >> move to make this a template class. This will allow better type
> > > checking
> > > > >> anytime we use it.
> > > > >>
> > > > >> An example of what is being planned is to change from
> > > > >>
> > > > >> MyClass object;
> > > > >> PdxWrapper((void *) object,...)
> > > > >> to PdxWrapper(object, )
> > > > >>
> > > > >> I have a chunk of code moved over that seems to show it is
> possible,
> > > > >> though there are some bugs that need to be addressed, so it is
> not a
> > > > done
> > > > >> deal.
> > > > >>
> > > > >> What do people think?
> > > > >>
> > > > >> Thanks,
> > > > >> Mark
> > > > >>
> > > >
> > > >
> > >
> >
>

CacheConnectionTimeoutJUnitTest and ClientHealthMonitorJUnitTest

2017-09-21 Thread Kirk Lund 
These two tests seem to be passing/failing about 50/50% of the time. I
recommend marking these as FlakyTest while the authors work on making them
pass 100%

:geode-protobuf:integrationTest

org.apache.geode.protocol.acceptance.CacheConnectionTimeoutJUnitTest >
testUnresponsiveClientsGetDisconnected FAILED
org.awaitility.core.ConditionTimeoutException: Condition defined as a
lambda expression in
org.apache.geode.protocol.acceptance.CacheConnectionTimeoutJUnitTest null
within 145 milliseconds.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
at
org.apache.geode.protocol.acceptance.CacheConnectionTimeoutJUnitTest.testUnresponsiveClientsGetDisconnected(CacheConnectionTimeoutJUnitTest.java:138)

14 tests completed, 1 failed

:geode-core:integrationTest

org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitorJUnitTest >
testDeadClientRemovalByServer FAILED
org.apache.geode.cache.client.ServerConnectivityException: Pool
unexpected closed socket on server connection=Pooled Connection to
localhost:22752: Connection[DESTROYED]). Server unreachable: could not
connect after 1 attempts
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:798)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:635)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:604)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:614)
at
org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:826)
at
org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:124)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.putOnForTestsOnly(ServerRegionProxy.java:177)
at
org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitorJUnitTest.testDeadClientRemovalByServer(ClientHealthMonitorJUnitTest.java:224)

Caused by:
java.io.EOFException: The connection has been reset while reading
the header
at
org.apache.geode.internal.cache.tier.sockets.Message.fetchHeader(Message.java:689)
at
org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndPayload(Message.java:703)
at
org.apache.geode.internal.cache.tier.sockets.Message.read(Message.java:652)
at
org.apache.geode.internal.cache.tier.sockets.Message.recv(Message.java:)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:469)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:392)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:278)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:332)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:900)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:599)
... 5 more

3761 tests completed, 1 failed, 141 skipped

DiskSpaceLimitIntegrationTest moved to FlakyTest

2017-09-21 Thread Kirk Lund 
I just moved DiskSpaceLimitIntegrationTest because GEODE-3205 continues to
intermittently fail.

I've already done a lot work to try and make the test pass consistently but
it's going to require a lot more tuning to make sure the files are just the
right size so that the StatSampler deletes them at exactly the right
expected times. It's very sensitive to timing and byte size of files.

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #685 has FAILED (2 tests failed). Change made by Mark Paluch.

2017-09-21 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #685 failed.
---
Scheduled with changes by Mark Paluch.
2/2037 tests failed.

https://build.spring.io/browse/SGF-NAG-685/

-
Currently Responsible
-

Mark Paluch (Automatically assigned)



--
Failing Jobs
--
  - Default Job (Default Stage): 2 of 2037 tests failed.



--
Code Changes
--
Mark Paluch (ad03f201cc16a0040616ffa82515b354b43d2639):

>DATAGEODE-42 - Downgrade to CDI 1.0.
>We now build against CDI 1.0 again while using CDI 2.0 for testing.

Mark Paluch (8626e1e7b084fae8d9cfa608ab452753ca25e9a5):

>DATAGEODE-43 - Added explicit automatic module name for JDK 9.



--
Tests
--
New Test Failures (2)
   - GemfireRepositoryBeanTest: 
Org.springframework.data.gemfire.repository.cdi. gemfire repository bean test
   - GemfireRepositoryExtensionTest: After bean discovery registers repository 
bean

--
This message is automatically generated by Atlassian Bamboo

Re: Need Help on understanding vsd files

2017-09-21 Thread Avinash Dongre 
Thanks Barry for your help and explanation.
Could you please re-attach the charts for the steps. I do not see them in
the email.

Thanks
Avinash


On Fri, Sep 22, 2017 at 2:30 AM, Barry Oglesby  wrote:

> You probably need more than just the getTime stat to see whats going on
> there. That stat is basically telling you how much time per second get
> operations are occurring. You probably need to also know how many gets are
> occurring.
>
> What I generally do is:
>
> - plot time stat (getTime in this case)
> - divide time stat by 100 to get milliseconds (top right in vsd)
> - plot operation stat (getsCompleted in this case)
> - change both to 'No Filter' (top right drop down in vsd). This tells you
> total time and number of operations.
> - Divide time stat by operations stat to get average time per operation.
> You can do this with either vsd or a calculator. I generally use a
> calculator and divide the maximum of each stat, but with vsd:
>   - select time stat line
>   - select 'Line' -> 'Divide Lines' menu option
>   - select operation stat line
>   - the last sample of the resulting line is the average for the entire run
>
> I attached charts for each step.
>
>
> Thanks,
> Barry Oglesby
>
>
> On Thu, Sep 21, 2017 at 10:29 AM, Anilkumar Gingade 
> wrote:
>
>> At a high level, you can find stat descriptions by "selecting a stat" and
>> then clicking (in vsd) main->"Show Statistic Info".
>>
>> -Anil.
>>
>>
>> On Thu, Sep 21, 2017 at 2:24 AM, Avinash Dongre 
>> wrote:
>>
>>> Attaching the graph.
>>>
>>> On Thu, Sep 21, 2017 at 2:45 PM, Avinash Dongre 
>>> wrote:
>>>
 Hi All,
>
> I am looking at  getTime-PartitionedRegionStats using vsd tools. I
> need some help on how to interpret following graph.
> If there is a document which helps to explain please let me know.
>
>
> [image: Inline image 1]
>
>
> Thanks
> Avinash
>
>

>>>
>>
>