[ANNOUNCE] Spring Session for Apache Geode 2.0.0.RC2 Available!

2017-11-29 Thread John Blum 
Greetings Apache Geode Community-

I am pleased to announce the release of *Spring Session for Apache Geode*
*2.0.0.RC2*.

The artifact is available from https://repo.spring.io/libs-milestone.

Simply include the following Maven dependency declaration...


org.springframework.session
spring-session-data-geode
2.0.0.RC2


And repository declaration...


  spring-libs-milestone
  Spring libs-milestone Maven Repository
  https://repo.spring.io/libs-milestone


This release includes the following improvements...

* Based on Spring Framework 5.0.2.RELEASE
* Based on Spring Boot 2.0.0.M6
* Based on Spring Data Kay-SR2
* Based on Spring Security 5.0.0.RELEASE
* Based on Spring Session core 2.0.0.RC2

* Updates Session event handling and notifications to appropriately handle
all Apache Geode "PROXY" Region types, both on the client as well as on the
server (think Region Data Accessors [1]).  SSDG also adapts to API changes
in *Spring Session* core to ensure all (Spring) Session events triggering *Java
Servlet* HttpSessionListeners contain a reference to the Session that
triggered the event.  Previously, in certain cases, *Spring Session* core
may only have included a reference to the Session's ID in the event.

GA is just around the corner and should be available sometime after *SpringOne
Platform 2017*.

If you have chance, be sure to try and get to the conference [2].  I will
be giving 3 talks this year, 2 of which involve Apache Geode with *Spring
Data* [3].

As always, any feedback is appreciated:

*GitHub* Issues [4], PR [5] or on *StackOverflow* [6].

That's all for now folks.

Cheers!

-- 
-John

[1]
http://geode.apache.org/docs/guide/12/developing/region_options/data_hosts_and_accessors.html
[2] https://springoneplatform.io/
[3] https://springoneplatform.io/speakers/john-blum
[4] https://github.com/spring-projects/spring-session-data-geode/issues
[5] https://github.com/spring-projects/spring-session-data-geode/pulls
[6] https://stackoverflow.com/questions/tagged/spring-session

Re: [DISCUSS] FunctionAdapter incompatible serialVersionUID

2017-11-29 Thread Alexander Murmann 
Even though the class is deprecated, you should be able to go from one
minor version to another without having to worry about anything breaking.
The point of semver is to provide information about things breaking or not
without having to read the changelog. If we remove APIs in a minor version
because they were previously deprecated we break that contract. Semver.org
 recommends
that the functionality should be marked as deprecated in a minor release
and then removed as part of a major release.

On Tue, Nov 28, 2017 at 7:03 PM, Jacob Barrett  wrote:

> Since the class was deprecated and is technically only there for pre-1.0
> compatibly then the behavior of this class should be consistent with the
> pre-1.0 version. This will break 1.0 to 1.3 but anyone coding to a post-1.0
> version should not be using this deprecated class.
>
>
> > On Nov 28, 2017, at 5:22 PM, Jason Huynh  wrote:
> >
> > *With your proposoal 1.0 - 1.3 users would have modify their source code
> on
> > the client and the server forthe function, correct?*
> >
> > If they start a new geode server 1.4+ and happened to extend
> > functionAdapter (it was deprecated in 1.0) then they would have to
> > recompile their client to not use functionAdapter.
> >
> > This should only affect users that extend FunctionAdapter and execute
> > functions by serializing them to the server from the client.  If they
> > execute by id it should not run into this problem...
> >
> >> On Tue, Nov 28, 2017 at 5:20 PM Jason Huynh  wrote:
> >>
> >> Dan, yeah, the suggested change in the stack overflow answer does work
> and
> >> I was able to put an if with the exact serialVersionUid before posting
> the
> >> proposal, but it is pretty hacky and may affect another class that
> somehow
> >> generated the same uid.  I can make that change too but I'd prefer not
> to
> >> have to maintain it moving forward...
> >>
> >>
> >>
> >>> On Tue, Nov 28, 2017 at 5:09 PM Dan Smith  wrote:
> >>>
> >>> I agree I don't think we can get rid of FunctionAdapter until the next
> >>> major version.
> >>>
> >>> I was thinking FunctionAdapter is rather widely used, but then I'm
> >>> surprised no one has hit this yet.
> >>>
> >>> All of the options kinda suck here - either pre 1.0 users have a
> >>> compatibility issue or 1.0-1.3 users do. With your proposoal 1.0 - 1.3
> >>> users would have modify their source code on the client and the server
> for
> >>> the function, correct?
> >>>
> >>> If we got really fancy we could actually ignore the serialVersionUUID
> for
> >>> this class like this - https://stackoverflow.com/a/1816711/2813144.
> But
> >>> it's pretty messy.
> >>>
> >>> -Dan
> >>>
> >>> On Tue, Nov 28, 2017 at 1:59 PM, Alexander Murmann <
> amurm...@pivotal.io>
> >>> wrote:
> >>>
>  Anil, I am not sure following. I think FunctionAdapter already is
>  deprecated. Isn't it? Anthony is right though that we shouldn't remove
>  anything customer facing unless we are doing a major release.
> Otherwise
> >>> we
>  are violating the contract provided by semantic versioning.
> 
>  On Tue, Nov 28, 2017 at 1:52 PM, Anilkumar Gingade <
> aging...@pivotal.io
> 
>  wrote:
> 
> > I haven't seen many uses of FunctionAdapter; if its not used much, I
>  think
> > we should deprecate this...
> >
> > It only provided default implementation for few of the methods; this
>  could
> > be added in the docs/release notes to help application to move to
>  function
> > implementation.
> >
> > -Anil.
> >
> >
> > On Tue, Nov 28, 2017 at 12:40 PM, Anthony Baker 
>  wrote:
> >
> >> I think we should wait for a major release to remove API’s.  If we
>  broke
> > a
> >> public API, we should fix that IMO.
> >>
> >> Anthony
> >>
> >>
> >>> On Nov 28, 2017, at 11:40 AM, Patrick Rhomberg <
> >>> prhomb...@pivotal.io
> >
> >> wrote:
> >>>
> >>> +1 to removing a long-deprecated class from the Geode side.
> >>>
> >>> On Tue, Nov 28, 2017 at 8:04 AM, Bruce Schuchardt <
> >> bschucha...@pivotal.io>
> >>> wrote:
> >>>
>  How about just getting rid of this class?  After all it was
> >>> marked
>  as
>  being deprecated in 1.0.  Pivotal could add a compatible
> > FunctionAdapter
>  class in their GemFire builds to support these old clients.
> 
> 
> 
> > On 11/27/17 10:18 AM, Jason Huynh wrote:
> >
> > This is a discussion for the fix to GEODE-4008:
> > InvalidClassException when deserializing FunctionAdapter from
> >>> pre
> > Geode
> > clients
> >
> > There was a change to deprecate FunctionAdapter in Geode (before
> > 1.0),
> >> and
> > this also removed the method signatures in the class. This
> >>> caused
> > Java
> >> to
> > generate a new

Re: [DISCUSS] FunctionAdapter incompatible serialVersionUID

2017-11-29 Thread Darrel Schneider 
+1 to not removing deprecated apis in minor releases.
The semver policy Alexander describes seems reasonable.
In the past of we have had something deprecated for a long time we have
felt free to remove it whenever we want but I think the semver policy is a
better way to decide when we are free to remove deprecated external apis.


On Wed, Nov 29, 2017 at 8:50 AM, Alexander Murmann 
wrote:

> Even though the class is deprecated, you should be able to go from one
> minor version to another without having to worry about anything breaking.
> The point of semver is to provide information about things breaking or not
> without having to read the changelog. If we remove APIs in a minor version
> because they were previously deprecated we break that contract. Semver.org
> 
> recommends
> that the functionality should be marked as deprecated in a minor release
> and then removed as part of a major release.
>
> On Tue, Nov 28, 2017 at 7:03 PM, Jacob Barrett 
> wrote:
>
> > Since the class was deprecated and is technically only there for pre-1.0
> > compatibly then the behavior of this class should be consistent with the
> > pre-1.0 version. This will break 1.0 to 1.3 but anyone coding to a
> post-1.0
> > version should not be using this deprecated class.
> >
> >
> > > On Nov 28, 2017, at 5:22 PM, Jason Huynh  wrote:
> > >
> > > *With your proposoal 1.0 - 1.3 users would have modify their source
> code
> > on
> > > the client and the server forthe function, correct?*
> > >
> > > If they start a new geode server 1.4+ and happened to extend
> > > functionAdapter (it was deprecated in 1.0) then they would have to
> > > recompile their client to not use functionAdapter.
> > >
> > > This should only affect users that extend FunctionAdapter and execute
> > > functions by serializing them to the server from the client.  If they
> > > execute by id it should not run into this problem...
> > >
> > >> On Tue, Nov 28, 2017 at 5:20 PM Jason Huynh 
> wrote:
> > >>
> > >> Dan, yeah, the suggested change in the stack overflow answer does work
> > and
> > >> I was able to put an if with the exact serialVersionUid before posting
> > the
> > >> proposal, but it is pretty hacky and may affect another class that
> > somehow
> > >> generated the same uid.  I can make that change too but I'd prefer not
> > to
> > >> have to maintain it moving forward...
> > >>
> > >>
> > >>
> > >>> On Tue, Nov 28, 2017 at 5:09 PM Dan Smith  wrote:
> > >>>
> > >>> I agree I don't think we can get rid of FunctionAdapter until the
> next
> > >>> major version.
> > >>>
> > >>> I was thinking FunctionAdapter is rather widely used, but then I'm
> > >>> surprised no one has hit this yet.
> > >>>
> > >>> All of the options kinda suck here - either pre 1.0 users have a
> > >>> compatibility issue or 1.0-1.3 users do. With your proposoal 1.0 -
> 1.3
> > >>> users would have modify their source code on the client and the
> server
> > for
> > >>> the function, correct?
> > >>>
> > >>> If we got really fancy we could actually ignore the serialVersionUUID
> > for
> > >>> this class like this - https://stackoverflow.com/a/1816711/2813144.
> > But
> > >>> it's pretty messy.
> > >>>
> > >>> -Dan
> > >>>
> > >>> On Tue, Nov 28, 2017 at 1:59 PM, Alexander Murmann <
> > amurm...@pivotal.io>
> > >>> wrote:
> > >>>
> >  Anil, I am not sure following. I think FunctionAdapter already is
> >  deprecated. Isn't it? Anthony is right though that we shouldn't
> remove
> >  anything customer facing unless we are doing a major release.
> > Otherwise
> > >>> we
> >  are violating the contract provided by semantic versioning.
> > 
> >  On Tue, Nov 28, 2017 at 1:52 PM, Anilkumar Gingade <
> > aging...@pivotal.io
> > 
> >  wrote:
> > 
> > > I haven't seen many uses of FunctionAdapter; if its not used much,
> I
> >  think
> > > we should deprecate this...
> > >
> > > It only provided default implementation for few of the methods;
> this
> >  could
> > > be added in the docs/release notes to help application to move to
> >  function
> > > implementation.
> > >
> > > -Anil.
> > >
> > >
> > > On Tue, Nov 28, 2017 at 12:40 PM, Anthony Baker  >
> >  wrote:
> > >
> > >> I think we should wait for a major release to remove API’s.  If we
> >  broke
> > > a
> > >> public API, we should fix that IMO.
> > >>
> > >> Anthony
> > >>
> > >>
> > >>> On Nov 28, 2017, at 11:40 AM, Patrick Rhomberg <
> > >>> prhomb...@pivotal.io
> > >
> > >> wrote:
> > >>>
> > >>> +1 to removing a long-deprecated class from the Geode side.
> > >>>
> > >>> On Tue, Nov 28, 2017 at 8:04 AM, Bruce Schuchardt <
> > >> bschucha...@pivotal.io>
> > >>> wrote:
> > >>>
> >  How about just getting rid of this class?  After all it was
> > >>> marked
> >  as
> >  being deprecated in 1

Re: DiskStore exception while region data evicted

2017-11-29 Thread Anilkumar Gingade 
So, when exception is reported, the producer is adding entries into the
region and eviction is overflowing the entries to disk...

Can you file a Geode Jira ticket for this...With the information you have
for reproducing...

Thanks,
-Anil.


On Wed, Nov 22, 2017 at 11:58 PM, Gregory Vortman <
gregory.vort...@amdocs.com> wrote:

> Hi,
> The node just stopped.
> In our test the issue is being reproduced whenever the producer
> continuously PUTs into the region, consumer stops GET and stops delete
> entries from the region.
> In a while, as long as eviction rate goes up, the exception occurs. We
> tested with GEODE 1.2.
> Here is the region definition:
>
> 
>  data-policy="partition" disk-store-name="ExternalRecord-overflow"
> disk-synchronous="false">
>  startup-recovery-delay="6" redundant-copies="1"
> colocated-with="PWINFO_1" total-num-buckets="251"/>
> 
>  action="overflow-to-disk"/>
> 
> 
>  from-clause="/EXTERNAL_RECORDS_1.entrySet
> e" expression="e.key.PartitionID"/>
>  from-clause="/EXTERNAL_RECORDS_1.entrySet
> e" expression="e.key.Index"/>
> 
> Thanks
>
> From: Anilkumar Gingade [mailto:aging...@pivotal.io]
> Sent: Wednesday, November 22, 2017 10:16 PM
> To: dev@geode.apache.org
> Cc: Gregory Vortman ; u...@geode.apache.org;
> *Technology - Digital - BSS – Charging - GEODE team <
> pbgrcmrmgeodet...@int.amdocs.com>; Victoria Boriskovsky <
> victo...@amdocs.com>
> Subject: Re: DiskStore exception while region data evicted
>
> Hi Gregory,
>
> Is the node stopped and restarted? If so how many times?
> It looks like the evict operation freed up 2401bytes...But at that time
> the current bucket size (as per stats) is (2401 -1425 =) 976bytes...Since
> the updated bucket memory stat was -ve, the system thrown exception...
>
> If you have reproducible scenario, can you send it across...Or steps to
> reproduce...
> Can you send your cache xml (or region configuration). And logs and stats
> if possible.
>
> -Anil.
>
>
>
> On Tue, Nov 21, 2017 at 9:04 AM, Guy Turkenits  mailto:guy.turken...@amdocs.com>> wrote:
> + Viki
>
> From: Gregory Vortman
> Sent: Tuesday, November 21, 2017 6:49 PM
> To: u...@geode.apache.org;
> dev@geode.apache.org
> Cc: *Technology - Digital - BSS – Charging - GEODE team <
> pbgrcmrmgeodet...@int.amdocs.com>;
> Guy Turkenits mailto:guy.turken...@amdocs.com>>
> Subject: DiskStore exception while region data evicted
>
> Hi team,
> One of the grid members went down and entire cache is closed whenever
> Partition region got an LRU threshold and overflow to disk is started:
> 
>
> Disk-store defined with 40GB.
>
> Actual metrics while crashed: entries on disk 70, bytes only on disk
> ~1GB.
> There is much room in the File system.
>
> Can you help to understand the following exception:
>
> [severe 2017/11/21 15:41:05.678 IST host1-pwinfo1  writer for region ExternalRecord-overflow> tid=0xdc] Fatal error from
> asynchronous flusher thread
> org.apache.geode.InternalGemFireError: Bucket
> BucketRegion[path='/__PR/_B__EXTERNAL__RECORDS__1_171;serial=6025;primary=true]
> size (-1425) negative after applying delta of -2401
> at org.apache.geode.internal.cache.BucketRegion.
> updateBucketMemoryStats(BucketRegion.java:2291)
> at org.apache.geode.internal.cache.BucketRegion.updateBucket2Size(
> BucketRegion.java:2279)
> at org.apache.geode.internal.cache.BucketRegion.updateSizeOnEvict(
> BucketRegion.java:2157)
> at org.apache.geode.internal.cache.DiskEntry$Helper.
> writeEntryToDisk(DiskEntry.java:1441)
> at org.apache.geode.internal.cache.DiskEntry$Helper.
> doAsyncFlush(DiskEntry.java:1388)
> at org.apache.geode.internal.cache.DiskStoreImpl$
> FlusherThread.run(DiskStoreImpl.java:1729)
> at java.lang.Thread.run(Thread.java:748)
>
> [error 2017/11/21 15:41:05.679 IST host1-pwinfo1  for region ExternalRecord-overflow> tid=0xdc] A DiskAccessException has
> occurred while writing to the disk for disk sto
> re ExternalRecord-overflow. The cache will be closed.
> org.apache.geode.cache.DiskAccessException: For DiskStore:
> ExternalRecord-overflow: Fatal error from asynchronous flusher thread,
> caused by org.apache.geode.InternalGemFireError: Bucket BucketRegion
> [path='/__PR/_B__EXTERNAL__RECORDS__1_171;serial=6025;primary=true] size
> (-1425) negative after applying delta of -2401
> at org.apache.geode.internal.cache.DiskStoreImpl$
> FlusherThread.run(DiskStoreImpl.java:1774)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.geode.InternalGemFireError: Bucket
> BucketRegion[path='/__PR/_B__EXTERNAL__RECORDS__1_171;serial=6025;primary=true]
> size (-1425) negative after applying delta of -2401
> at org.apache.geode.internal.c

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #751 was SUCCESSFUL (with 2264 tests). Change made by John Blum.

2017-11-29 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #751 was successful.
---
Scheduled with changes by John Blum.
2266 tests in total.

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




--
Code Changes
--
John Blum (d20111badae489b82be39fb0f7d9651608b2b272):

>DATAGEODE-69 - Dependency on org.iq80.snappy:snappy breaks the IO Platform 
>build and appears to be a candidate for being test scoped.



--
This message is automatically generated by Atlassian Bamboo