Member introduction

[Alex Snaps]

We had a couple of people joining this effort already, aside from the ones I forced to join... Terracotta employees basically. At least the one that were brave enough to take upon even more work and dedicate some of their own time to this effort. Now the reward should be worth it, for all of us :) 

It might be a good time to actually introduce ourselves here, and have newcomers use this thread to get a chance to introduce themselves too.

So let me kick this off: I'm Alex Snaps, Principal Software Engineer at Terracotta. Have been working there for close to 5 years now and for over 4 years on Ehcache, on basically every single aspect of it. I'd like to see Ehcache become much more user friendly. As an API geek, I hope for Ehcache's to be seriously cleaned up and become more cohesive. Internally, while I'm responsible for much of the mess that's currently in the 2.x line, I think we have to come up with a much simpler and cleaner design. One that will support the features that are now part of the 2.x line and the ones to come. 

Looking forward to make that happen :)
Alex 

[Chris Dennis]

I’m Chris Dennis, a senior software engineer at Terracotta.  I’ve been working at Terracotta for a little over 5 years, and have during that time worked on almost all aspects of the client side code at Terracotta, including most of the parts of Ehcache.  I’m also Software AG’s representative on the JSR-107 expert group.  I come from an academic non-CS background and have never worked in the ‘user’ side of Java EE.  In this sense my knowledge on caching comes very much from the implementation side, and I have a strange aversion to logically inconsistent API designs.  I’m also a proponent of a 'strong' API, I like – strong type systems, aggressive type safety, checked exceptions etc.  I’m also occasionally prone to calling spades, spades – I don’t usually mean any offense.

Looking forward to spirited discussions,

Chris

[Ben Cotton]

Sorry this is long, but I want to be clear as to why we are here.  My name is Ben Cotton, I am an HPC Linux Supercomputing consultant at JPMorgan.  We use quantitative algorithms to render and aggregate real-time liquidity risk so that banking stakeholders can answer this primordial question "What is my Liquidity Risk indicator (LRI) for any Position (P) on any Asset Class (A) at any Time (t)?"  This is is a hard question to answer in real-time on a $3T balance sheet. I am not loyal to any programming language.  I have equal competencies in Unix/C/C++, KX/KDB+/Q, and/or Java.  I find that with Java, I get a lot of "Developer velocity" generated for my team.  I like that.  I don't like that Java is damn glued to its vain belief that a GC-managed run-time is elegant.  I believe in sound/complete APIs.  I don't care about API elegance and/or any OOAD high-priests telling me a design is "non-elegant".  We need capability more than elegance.  Like Dennis, I also sit on JSR-107, but I come there, like we come here, only to represent the Wall St. interest to solve the generic data locality, latency, and caching problems (strictly a user-view we have never coded/built a Java product).  My team wants to see if Java technology can help us here.  We have our concerns.  I'm here to see how Open EhCache DEV can help.  You guys damn well better accommodate the notion of empowering us as community to help you build an ultra-high-performance Off-Heap javax.cache.Cache<K,V> impl.  We are concerned because neither HZ nor TC open-source their off-heap "Big Memory" products.  So we reject them. We use infinispan because their attitude is perfect: EVERYTHING OPEN SOURCE IN EVERY WAY.  We are also concerned because TC rejected JSR-347.  Why?  Tons of problems are addressed by 347 that 107 did not.  Explain this please. You guys are TC, but I bet you may in fact be disappointed with that vote.  Any way, I'm hear because I am loyal to solving problems and you guys have some talent.  I hope I can bring a user's generic view of what we need in a solution.  If you find that helpful to you, great.  If not, just tell us, we're outta here.  Either way, best wishes to this effort, we'll be watching.

[Alex Snaps]

The whole OSS vs. commercial isn't something anyone here controls. Nothing we can do about it here certainly. 

On the JSR-347 subject, I am sorry but I am unable to discuss what Greg was thinking when he voted the way he did. Developers on this group are certainly all for 347 and whatever is relevant in the context of Ehcache will certainly be considered.

(Sorry for hijacking this thread responding to these questions, but I think they deserved some form of answers, back to intros here now :)

On Thu, Feb 27, 2014 at 11:33 AM, Ben Cotton <bendc...@gmail.com> wrote:

Sorry this is long, but I want to be clear as to why we are here.  My name is Ben Cotton, I am an HPC Linux Supercomputing consultant at JPMorgan.  We use quantitative algorithms to render and aggregate real-time liquidity risk so that banking stakeholders can answer this primordial question "What is my Liquidity Risk indicator (LRI) for any Position (P) on any Asset Class (A) at any Time (t)?"  This is is a hard question to answer in real-time on a $3T balance sheet. I am not loyal to any programming language.  I have equal competencies in Unix/C/C++, KX/KDB+/Q, and/or Java.  I find that with Java, I get a lot of "Developer velocity" generated for my team.  I like that.  I don't like that Java is damn glued to its vain belief that a GC-managed run-time is elegant.  I believe in sound/complete APIs.  I don't care about API elegance and/or any OOAD high-priests telling me a design is "non-elegant".  We need capability more than elegance.  Like Dennis, I also sit on JSR-107, but I come there, like we come here, only to represent the Wall St. interest to solve the generic data locality, latency, and caching problems (strictly a user-view we have never coded/built a Java product).  My team wants to see if Java technology can help us here.  We have our concerns.  I'm here to see how Open EhCache DEV can help.  You guys damn well better accommodate the notion of empowering us as community to help you build an ultra-high-performance Off-Heap javax.cache.Cache<K,V> impl.  We are concerned because neither HZ nor TC open-source their off-heap "Big Memory" products.  So we reject them. We use infinispan because their attitude is perfect: EVERYTHING OPEN SOURCE IN EVERY WAY.  We are also concerned because TC rejected JSR-347.  Why?  Tons of problems are addressed by 347 that 107 did not.  Explain this please. You guys are TC, but I bet you may in fact be disappointed with that vote.  Any way, I'm hear because I am loyal to solving problems and you guys have some talent.  I hope I can bring a user's generic view of what we need in a solution.  If you find that helpful to you, great.  If not, just tell us, we're outta here.  Either way, best wishes to this effort, we'll be watching.

--
You received this message because you are subscribed to the Google Groups "ehcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/57159013-5bfc-4d43-a444-9625e71b0bfc%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Alex Snaps <alex....@gmail.com>
Principal Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
http://withinthefra.me

[Cotton, Ben]

I apologize (emphatically).  Outright rude of me.

 

P.S. thank you Alex for this response.  I feel you guys.  I like it here.  Nuff, said.

 

P.P.S  Please others, do introduce yourselves.

 

 

 

Ben D. Cotton III
J.P.Morgan
Liquidity Risk Technology
277 Park Ave  Desk 08-GG64
New York, NY 10172-0003
212.622.5010
ben.c...@jpmorgan.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/CAKux6pZgq3Oikbko19%2BqtwTEZy%3DDVjxCp%2B3aToRoqFL44aDRxQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

[Louis Jacomet]

Hello all,

My name is Louis Jacomet, I am a Senior Software Engineer at Terracotta for a bit more than a year.

Before joining Terracotta, I have been working as a contractor in Belgium, for different clients in different businesses.

Since I started at Terracotta, I have been working on Ehcache, mostly in the public facing things, fixing bugs, improving features interactions and more. This has sometimes been a frustrating exercise as we have to tread carefully, since compatibility is very important for us, on behalf of our users.

In this light, I am really awaiting a lot from this open Ehcache 3.0 design. Asking community for what's important in Ehcache and thus should be around in the next major version is one aspect of it. But also knowing what kind of changes are considered valuable and thus allow us to move further, preparing for the next Ehcache generation.

Let's get this rolling!

Louis

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/5E52BF1ABBD2A64986C1CB3D207DAB0607022285%40SEGCMX039.exchad.jpmchase.net.

[Ludovic Orban]

Hi,

My name is Ludovic Orban and I've been working for terracotta for almost 5 years now, on almost all aspects of Ehcache. In my previous life, I worked on transactional systems of all kinds which pushed me to author the Bitronix JTA transaction manager to try to make the (transactional) world a better place. I also am the main author and maintainer of the Ehcache transactional features.

Now that I've joined the Ehcache 3 task force, I'll do my best to help you guys make it rock!

--
Ludovic

[Vitaliy Funshteyn]

Hello!

I am a software engineer with Terracotta, initially with the platform team that was responsible for all the plumbing that makes clustered Ehcache work, i.e. client/server components that underpin the BigMemory platform. My primary area of focus has been design, development and optimization of public and non-public facing aspects of all things related to search across the stack, starting from relevant Ehcache APIs, all the way down to the low level subsystem that actually enables our platform's search features. I have also worked on the WAN replication module which is used for real-time data replication between Terracotta clusters in separate data centers.

I enjoy collaborating on complex and challenging projects and providing meaningful critique where applicable (or so I hope), and look forward to contributing to the formation of what is sure to become the best Ehcache yet. :)

Vitaliy

[Clifford Johnson]

I am a recent addition to the Software AG / Terracotta / Ehcache crew.  I joined the company in September 2014.

Before joining Software AG, I spent many years (too many to admit) working for various software companies of various sizes including several (dissapointly) failed startups.  The roles were varied but never too far from the code.  My life with commercial software companies began with quite a few years as an IBM S/370 Assembler programmer producing system management.  The transition to the Java ecosystem came during a stint with a database technology company and continued (with an interruption to try C# and MS Office apps) through to the current day.  Most of my development work has been on infrastructure and frameworks -- which will hopefully play well with the needs of Ehcache 3.

--

Clifford

[kareem shabazz]

Greetings -

I am Kareem Shabazz, senior software engineer and a director of software engineering @ UBS where I am primarily concerned with real time inventory management there - inventory management here means collateral(repos,outrights etc) management, knowing what the firm's position is at any given time. To this end we utilize Ehcache as the caching layer (one of) for our numerous calls to external systems to "enrich" the heterogeneous data that we deal with. Prior to this I've had extensive experience with Gemfire for many years for dealing with order/trade executions.  I basically liked what I read here from Alex and I would like to actively participate in helping this along.

[Alex Snaps]

Hey Kareem, 

First, welcome! It's always nice to see initiatives like this one gaining traction...

That being said, is there anything you'd expect from us? I guess you've been going through the code somewhat already... I can imagine lots of questions emerging from this! ;)

I'm currently trying to address some of that through documentation. But it's hard to guess what should get more coverage et al... Anyways, if you have questions or feedback, don't hesitate! And, again, welcome!

Alex

[Kareem Shabazz]

Well I'm not coming from the perspective of needing anything from you guys in terms of features - whatever I (or my team) needed we bolted on to Ehcache. So for instance you mentioned "Refresh Ahead" so we hacked on something similar where we were getting loads of instrument enrichment data from a "master source" via REST but at the same time didn't want to be tightly coupled to it and didn't want our data getting stale so on the weekend at a set time we would "refresh" the data we had, updating any stale keys and throwing out any outdated ones "ahead" of the weeks activities.

So a more robust, built in implementation of that would be a nice-to-have if this is the use case you are looking at or something along those lines. 

My main question is if you are not from Terracotta how can you contribute? My other question is how do we make the API (and code landscape) ready for JDK8 (Lambdas specifically) while  not discriminating against a JDK6 user?

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "ehcache-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ehcache-dev/yMyVCU3EGrs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ehcache-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/5cbc3eca-8f06-4d46-9d9d-ba96ca95401d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rajesh B]

Hello Alex,

I want to be part of opensource developer community so that I can contribute myself for the development of ehcache. I know brief overview of it. Can you please let me know how this community works and how can I start working on it. I work for SoftwareAG

Thanks,

Rajesh.

[James House]

Hi Rajesh,  Welcome.

Simply start contributing to conversations and start your own conversations to make proposals for code, docs, or other contributions that you would like to make.   

You can also take a look at the project on github and pick out any open issues that you'd like to tackle, help review pull requests, and etc..

As you become more comfortable with the project, and gain confidence of others, your position within the community should naturally mature along with your level of contribution.

--

You received this message because you are subscribed to the Google Groups "ehcache-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/d26e10cc-1311-4eb2-8400-bf20706eb1e1%40googlegroups.com.

[Priya Aggarwal]

Hi Alex,

It is very nice of you to start a thread to let new members introduce themselves. 

I am Priya Aggarwal, software engineer at Expedia Inc. I have always been on office development projects and never an opensource one. 

I wish to begin my open-source career with Ehcache. And working on understanding how everything works here would be a great learning opportunity for me, and I am looking forward to each issue I might face when setting up project on my local machine, things which I may not understand so easily and mistakes I might make that need me to study new tech articles.

Thank you!

Best,

Priya Aggarwal

[Jayanta Mandal]

Hi Alex,

My name is Jayanta, I work in a software company based in Hyderabad, India. Recently I got a research-oriented task where I need to disable/refresh server caches so that users can get updated values in the result. I'm looking for a solution to implement centralized caching. Is it possible using EhCache? If yes, that would be great. 

My problem is very straightforward. Two different application servers point to the same database. One of them is dedicated for xml-request/response. The other server, which in fact is a replica of the first, is used to access the application and to do the majority of the work. Now any changes in the database-side, if user wants to do, they do so through the second server only. If the first server sends a request-xml, it is not able to get the updated response. as the update in DB happened from the second server. So I'm stuck with some manual task - like clearing the caches from the first server every now and then.

Instead of this, if I can come across a solution, where both the server caches come in sync, and they get updated simultaneously, my job would be done. 

Pls see if I can achieve this using this Api. Thanks.

[Henri Tremblay]

You are not speaking to Alex anymore but to the entire ehcache mailing list.

You can achieve this using clustering. By clustering your cache and invalidating the obsolete entry on one server, it will automatically get invalidated to the other server.

See http://www.ehcache.org/documentation/3.4/clustered-cache.html

--

You received this message because you are subscribed to the Google Groups "ehcache-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/9e8e351f-f5bc-4f4b-890d-34eac29f86b9%40googlegroups.com.

[Jayanta]

Hey Henry,

Thanks for the suggestion. "Clustered computing" is a new topic for me. You gave me a good hint, I will try it this way.

Best regards,

--
You received this message because you are subscribed to a topic in the Google Groups "ehcache-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ehcache-dev/yMyVCU3EGrs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ehcache-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/CADZL2%3DuX2_D%2BTin4dSO4PAaX0f18N0U5ZypnYHaHbcJBiaPnbw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

------
With Best Wishes,
Jayanta Mandal
Hyderabad, India

[Louis Jacomet]

Hi Jayanta,

Also for your information, this list is the one dedicated to questions around Ehcache development. We have another list, ehcache-users, for usage, best practices and other consumer oriented questions.

Regards,

Louis

On Thu, Nov 16, 2017 at 8:27 AM Jayanta <jay.s...@gmail.com> wrote:

Hey Henry,

Thanks for the suggestion. "Clustered computing" is a new topic for me. You gave me a good hint, I will try it this way.

Best regards,

On 15 November 2017 at 21:04, Henri Tremblay <henri.t...@gmail.com> wrote:

You are not speaking to Alex anymore but to the entire ehcache mailing list.

You can achieve this using clustering. By clustering your cache and invalidating the obsolete entry on one server, it will automatically get invalidated to the other server.

See http://www.ehcache.org/documentation/3.4/clustered-cache.html

On 15 November 2017 at 08:26, Jayanta Mandal <jay.s...@gmail.com> wrote:

Hi Alex,

My name is Jayanta, I work in a software company based in Hyderabad, India. Recently I got a research-oriented task where I need to disable/refresh server caches so that users can get updated values in the result. I'm looking for a solution to implement centralized caching. Is it possible using EhCache? If yes, that would be great. 

My problem is very straightforward. Two different application servers point to the same database. One of them is dedicated for xml-request/response. The other server, which in fact is a replica of the first, is used to access the application and to do the majority of the work. Now any changes in the database-side, if user wants to do, they do so through the second server only. If the first server sends a request-xml, it is not able to get the updated response. as the update in DB happened from the second server. So I'm stuck with some manual task - like clearing the caches from the first server every now and then.

Instead of this, if I can come across a solution, where both the server caches come in sync, and they get updated simultaneously, my job would be done. 

Pls see if I can achieve this using this Api. Thanks.

On Thursday, February 27, 2014 at 7:27:19 PM UTC+5:30, Alex Snaps wrote:

We had a couple of people joining this effort already, aside from the ones I forced to join... Terracotta employees basically. At least the one that were brave enough to take upon even more work and dedicate some of their own time to this effort. Now the reward should be worth it, for all of us :) 

It might be a good time to actually introduce ourselves here, and have newcomers use this thread to get a chance to introduce themselves too.

So let me kick this off: I'm Alex Snaps, Principal Software Engineer at Terracotta. Have been working there for close to 5 years now and for over 4 years on Ehcache, on basically every single aspect of it. I'd like to see Ehcache become much more user friendly. As an API geek, I hope for Ehcache's to be seriously cleaned up and become more cohesive. Internally, while I'm responsible for much of the mess that's currently in the 2.x line, I think we have to come up with a much simpler and cleaner design. One that will support the features that are now part of the 2.x line and the ones to come. 

Looking forward to make that happen :)
Alex 

--
You received this message because you are subscribed to the Google Groups "ehcache-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/9e8e351f-f5bc-4f4b-890d-34eac29f86b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "ehcache-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ehcache-dev/yMyVCU3EGrs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ehcache-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/CADZL2%3DuX2_D%2BTin4dSO4PAaX0f18N0U5ZypnYHaHbcJBiaPnbw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

------
With Best Wishes,
Jayanta Mandal
Hyderabad, India

--

You received this message because you are subscribed to the Google Groups "ehcache-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/CAKw2XmjYBYUbck-nbA5ZjP02EYw72eTBkESoGdX-Pq8Qrhjkng%40mail.gmail.com.