+1
We are attempting the same on the non-Java clients too.
-Jake
On Mon, Apr 3, 2017 at 1:30 PM Kirk Lund wrote:
> My primary goal is to defer instantiating the Command instances until after
> the Cache has initialized Security. I then have several options for
> handling Security within the C
My primary goal is to defer instantiating the Command instances until after
the Cache has initialized Security. I then have several options for
handling Security within the Commands that has much less performance impact
than it currently has. A major reconfiguration or lifecycle point, such as
clos
I'm not against refactoring the command classes. They originated from
the refactoring of a very large method that attempted to handle all
client operations and, consequently, are currently stateless. You can't
really hurt anything by creating multiple instances of them but please
avoid creatin
+1 to getting rid of singletons and non-constant use of static. Also to
code where the ownership semantics are clear.
On Mon, Apr 3, 2017 at 10:30 AM, Jacob Barrett wrote:
> +1 refactor
> On Mon, Apr 3, 2017 at 9:35 AM Michael William Dodge
> wrote:
>
> > +1 to modular and questioning non-const
+1 refactor
On Mon, Apr 3, 2017 at 9:35 AM Michael William Dodge
wrote:
> +1 to modular and questioning non-constant use of static
>
> > On 3 Apr, 2017, at 09:27, Anthony Baker wrote:
> >
> > Using singletons leads to very monolithic systems that are hard to test
> and hard to change. Instead w
+1 to modular and questioning non-constant use of static
> On 3 Apr, 2017, at 09:27, Anthony Baker wrote:
>
> Using singletons leads to very monolithic systems that are hard to test and
> hard to change. Instead we should prefer modular services like Udo proposed.
>
> I would go further and s
Using singletons leads to very monolithic systems that are hard to test and
hard to change. Instead we should prefer modular services like Udo proposed.
I would go further and say that we should question any non-constant use of
“static”.
Anthony
> On Apr 3, 2017, at 9:01 AM, Udo Kohlmeyer wr
Correct, that would be the definition.
Yet, we find that our use of singletons within Geode is limiting to say
that least. With the idea of wanting to be able to create/run multiple
cache instance within the same JVM (especially for testing) a singleton
will be problematic.
In addition to th
Isn't "that instance is reused each invocation" my understanding of a
"singleton"?
On Mon, Apr 3, 2017 at 11:49 AM, Udo Kohlmeyer
wrote:
> -1 For using singletons
>
> Using a Factory pattern you can avoid having to create singletons in
> addition to caching created commands to avoid the recreati
-1 For using singletons
Using a Factory pattern you can avoid having to create singletons in
addition to caching created commands to avoid the recreation of the
instance.
The SSLConfigurationFactory is a simple example where you create an
instance when required. Once an instance is created,
I think the client commands needs to be singleton instances even after you
change the sequence of initialization. We don't want to have each client
operation ends up creating a new command instance, right? That would be a
more performance drag.
On Thu, Mar 30, 2017 at 2:14 PM, Kirk Lund wrote:
>
PS: I'll be writing and using JMH benchmarks to drive these changes. I'll
also create new unit tests for each of these classes that don't currently
have unit tests.
On Thu, Mar 30, 2017 at 10:58 AM, Kirk Lund wrote:
> The client Commands now check with SecurityService even when security is
> not
12 matches
Mail list logo
