Well, a transactional cache still implements the JCache spec, so we need to
provide these metrics with some meaningful semantics. Agree that mixing
implicit and explicit txs will mess up the metrics, but I doubt we can do
anything about it.
2017-09-20 20:38 GMT+03:00 Andrey Gura :
> Alexey,
>
> i
Firstly all, why not call it DataPolicy instead of MemoryPolicy? Secondly,
why not set data policies directly on IgniteConfiguration. And lastly, how
about we combine memory and disk properties in one bean with clear naming
convention?
Here is the example. Note that all properties above must start
redtank created IGNITE-6462:
---
Summary: @SpringResource block Service Node bootstrap when the
node starts at the first time
Key: IGNITE-6462
URL: https://issues.apache.org/jira/browse/IGNITE-6462
Project: Ig
Alexey Kuznetsov created IGNITE-6461:
Summary: Web Console: sanitize user on save
Key: IGNITE-6461
URL: https://issues.apache.org/jira/browse/IGNITE-6461
Project: Ignite
Issue Type: Bug
+1 on idea (long overdue) and +1 on using epics in JIRA for grouping IEPs.
--
Nikita Ivanov
On Wed, Sep 20, 2017 at 10:28 PM, Denis Magda wrote:
> Vladimir,
>
> I support your initiative because it sorts things out and brings more
> transparency to Ignite community.
>
> The only moment that bo
Denis, the argument sounds convincing to me. When you use 3rd party DB, you
rarely have to care how to migrate DB data.
Igniters, I suggest keeping compatibility as long as we can, even with the
transition to a new major release. If incompatibility will become
unavoidable we will consider migratio
Either 3 or 4 looks as an appropriate approach for me. Ignite is no longer just
an in-memory storage and we can not afford to force our users to migrate the
data or configuration just because of the new cool feature in a new version. We
should provide the same level of compatibility as RDBMS ven
Github user knovik closed the pull request at:
https://github.com/apache/ignite/pull/2708
---
GitHub user knovik opened a pull request:
https://github.com/apache/ignite/pull/2708
IGNITE-3935 Test on deserialization from different nodes
ClassloaderSwitchSelfTest.java implements a test-case where class loaders
should be switched to the peer-class-loading loader refering to IGN
GitHub user EdShangGG opened a pull request:
https://github.com/apache/ignite/pull/2707
IGNITE-6460 Wrong consistentId for lightweight ClusterNode instances
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite i
Eduard Shangareev created IGNITE-6460:
-
Summary: Wrong consistentId for lightweight ClusterNode instances
Key: IGNITE-6460
URL: https://issues.apache.org/jira/browse/IGNITE-6460
Project: Ignite
Vladimir,
My only concern is the tickets aggregation in JIRA. The labels approach is not
generic and flexible, requires me to use specific filters and use some numeric
form for labels. However, if all the tickets listed in an IEP were grouped
under an umbrella ticket or epic this would make all
Denis,
I do not very like that idea. If you look at other projects, you'll notice
that in general they use either WIKIs (e.g. HZ), or JIRA (e.g. Spark), but
not both. Only one reason - to avoid complication and keep the process as
light as possible, which is important for community.
Choosing betw
On Wed, Sep 20, 2017 at 6:37 AM, Igor Sapego wrote:
> For example, some users may want to disable clients they are not
> using due to security considerations.
>
Well, there should be some authentication command in the protocol, which
will ask a client to login. Ignite should also provide a conne
Vladimir,
I support your initiative because it sorts things out and brings more
transparency to Ignite community.
The only moment that bothers me is how the tickets, falling into a specific
IEP, are *grouped in JIRA*. Instead of labels I would advise us to use umbrella
tickets or epics. I pref
Alexey,
implicit transactions still can cause problems in metrics interpretation:
- locks acquiring is still needed;
- metrics that taken in account for implicit transactions and missed
metrics for explicit transactions for the same cache still can
confuse.
On Wed, Sep 20, 2017 at 6:02 PM, Alexe
Igniters,
The compatibility testing framework [1] will be completed soon.
We will be able to cover all the cases suggested by Vladimir, for example:
>> 2) No compatibility, but provide migration instruments
It will be possible to test migration tools and scenarios provided to the
end users.
Some
Agree with Andrey here. Probably, we can keep existing JCache metrics for
implicit transactions, but we should design a whole new interface to handle
transaction metrics, including various transaction stages, such as lock
acquisition, prepare and commit phases. In my opinion, this is the only way
t
Slava and Igniters,
Do you have any suggestions about described problem?
>From my point of view JCache API metrics specification has a number of
statements that can't be uniquely treated by Ignite user because of
implementations details. Most obvious problems here are related with
transactions th
GitHub user mcherkasov opened a pull request:
https://github.com/apache/ignite/pull/2706
Ignite 2.1.4 p3
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2.1.4-p3
Alternatively you can review and app
Semen Boikov created IGNITE-6459:
Summary: Implement metrics to monitor mvcc coordinator performance
Key: IGNITE-6459
URL: https://issues.apache.org/jira/browse/IGNITE-6459
Project: Ignite
Is
Semen Boikov created IGNITE-6458:
Summary: Implement possibility to manually change mvcc coordinator
Key: IGNITE-6458
URL: https://issues.apache.org/jira/browse/IGNITE-6458
Project: Ignite
Is
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2698
---
GitHub user zstan opened a pull request:
https://github.com/apache/ignite/pull/2705
IGNITE-584: proper datastructures setDataMap fill while new node append
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ig
Ilya Suntsov created IGNITE-6457:
Summary: Incorrect exception when used schema name in lower case
Key: IGNITE-6457
URL: https://issues.apache.org/jira/browse/IGNITE-6457
Project: Ignite
Iss
For example, some users may want to disable clients they are not
using due to security considerations.
Best Regards,
Igor
On Wed, Sep 20, 2017 at 4:13 PM, Dmitriy Setrakyan
wrote:
> Why do we need the ability to disable individual clients?
>
> On Wed, Sep 20, 2017 at 5:26 AM, Igor Sapego wrote
Why do we need the ability to disable individual clients?
On Wed, Sep 20, 2017 at 5:26 AM, Igor Sapego wrote:
> I've filed a ticket for that: [1]
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-6456
>
> Best Regards,
> Igor
>
> On Wed, Sep 20, 2017 at 2:33 PM, Vladimir Ozerov
> wrote:
>
GitHub user dspavlov opened a pull request:
https://github.com/apache/ignite/pull/2704
IGNITE-6454: suite timeout replace to failure
Interrupted flag check was added
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-
GitHub user alexzaitzev opened a pull request:
https://github.com/apache/ignite/pull/2703
PR to add branch to TC
Change was made to create PR for TC to run tests on version Apache Ignite
2.1
You can merge this pull request into a Git repository by running:
$ git pull https://g
Igor Sapego created IGNITE-6456:
---
Summary: Add flags to ClientConnectorConfiguration which
enable/disable different clients
Key: IGNITE-6456
URL: https://issues.apache.org/jira/browse/IGNITE-6456
Projec
I've filed a ticket for that: [1]
[1] - https://issues.apache.org/jira/browse/IGNITE-6456
Best Regards,
Igor
On Wed, Sep 20, 2017 at 2:33 PM, Vladimir Ozerov
wrote:
> Agree. Do we have a ticket for this?
>
> On Wed, Sep 20, 2017 at 1:27 PM, Pavel Tupitsyn
> wrote:
>
> > Yes, I think it would
Igor Sapego created IGNITE-6455:
---
Summary: Add flags to ClientConnectorConfiguration which
enable/disable different clients
Key: IGNITE-6455
URL: https://issues.apache.org/jira/browse/IGNITE-6455
Projec
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/2702
IGNITE-6448: clear query cache on ALTER TABLE ADD
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6448
I prefer the second. Composition over inheritance - this is how all our
configuration is crafted.
E.g. we do not have "CacheConfiguration" and "StoreEnabledCacheConfiguration".
Instead, we have "CacheConfiguration.setCacheStoreFactory".
On Wed, Sep 20, 2017 at 2:46 PM, Alexey Goncharuk <
alexey.g
Reiterating this based on some feedback from PDS users.
It might be confusing to configure persistence with "MemoryPolicy", so
another approach is to deprecate the old names and introduce a new name
"DataRegion" because it reflects the actual state when data is stored on
disk and partially in memo
Agree. Do we have a ticket for this?
On Wed, Sep 20, 2017 at 1:27 PM, Pavel Tupitsyn
wrote:
> Yes, I think it would make sense to add enableJdbc, enableOdbc,
> enableThinClients
> properties to ClientConnectorConfiguration (which replaces
> SqlConnectorConfiguration).
>
> This way users will als
Dmitriy Pavlov created IGNITE-6454:
--
Summary: Data structure suite timeout
Key: IGNITE-6454
URL: https://issues.apache.org/jira/browse/IGNITE-6454
Project: Ignite
Issue Type: Bug
Affects
Yes, I think it would make sense to add enableJdbc, enableOdbc,
enableThinClients
properties to ClientConnectorConfiguration (which replaces
SqlConnectorConfiguration).
This way users will also have better understanding of the
ClientConnectorConfiguration purpose.
Pavel
On Wed, Sep 20, 2017 at 1
Hi, Igniters,
In current approach, ODBC, thin JDBC and thin .NET client all connect
to the grid using ClientListenerProcessor, which listen on a single port.
The problem is that there is currently no way to disable only one client.
For example, currently you can't disallow thin JDBC driver connec
Pavel Tupitsyn created IGNITE-6453:
--
Summary: .NET: Thin client: cache operations
Key: IGNITE-6453
URL: https://issues.apache.org/jira/browse/IGNITE-6453
Project: Ignite
Issue Type: Improvem
Ivan Rakov created IGNITE-6452:
--
Summary: Invocation of getAll() through cache proxy during cache
restart can throw unexpected CacheException
Key: IGNITE-6452
URL: https://issues.apache.org/jira/browse/IGNITE-6452
redtank created IGNITE-6450:
---
Summary: Kotlin: Inherited platform declarations clash
Key: IGNITE-6450
URL: https://issues.apache.org/jira/browse/IGNITE-6450
Project: Ignite
Issue Type: Bug
Alexander Belyak created IGNITE-6451:
Summary: AssertionError: null in GridCacheIoManager.onSend on stop
Key: IGNITE-6451
URL: https://issues.apache.org/jira/browse/IGNITE-6451
Project: Ignite
Vasiliy Sisko created IGNITE-6449:
-
Summary: Visor CMD: Show missed cache properties
Key: IGNITE-6449
URL: https://issues.apache.org/jira/browse/IGNITE-6449
Project: Ignite
Issue Type: Bug
Ilya Suntsov created IGNITE-6448:
Summary: Select * doesn't return new field name after concurrent
ALTER TABLE
Key: IGNITE-6448
URL: https://issues.apache.org/jira/browse/IGNITE-6448
Project: Ignite
Yes, we'll add this validation.
On Wed, Sep 20, 2017 at 10:09 AM, Dmitriy Setrakyan
wrote:
> On Tue, Sep 19, 2017 at 11:31 PM, Semyon Boikov
> wrote:
>
> > > Can caches within the same group have different MVCC configuration?
> >
> > Do you think we really need have in the same group caches wit
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/2701
IGNITE-6316
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6316
Alternatively you can review and apply th
On Tue, Sep 19, 2017 at 11:31 PM, Semyon Boikov
wrote:
> > Can caches within the same group have different MVCC configuration?
>
> Do you think we really need have in the same group caches with different
> mvcc configuration? for simplicity I would do not allow this.
>
I agree, let's not allow i
48 matches
Mail list logo
