[jira] [Created] (IGNITE-2767) Cont. query remote filter requires to be in client nodes class path
Denis Magda created IGNITE-2767:
---
Summary: Cont. query remote filter requires to be in client nodes
class path
Key: IGNITE-2767
URL: https://issues.apache.org/jira/browse/IGNITE-2767
Project: Ignite
Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Fix For: 1.6
Cont. query remote filter has to be placed to class path of all client nodes
otherwise the following exception happens
{noformat}
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas [ ] [1]
[tcp-disco-msg-worker-#2%cas-grid%] : Failed to unmarshal discovery data for
component: 0 [TcpDiscoverySpi]
2016-03-04T15:08:24.259Z ERR cas org.apache.ignite.IgniteCheckedException:
Failed to find class with given class loader for unmarshalling (make sure same
versions of all classes are available
on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@18b4aac2
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:108)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:78)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1717)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:3685)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2252)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5789)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2161)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas Caused by:
java.lang.ClassNotFoundException: com.ringcentral.tap_api.ha.RemoteFilterWrapper
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.net.URLClassLoader.findClass(URLClassLoader.java:381)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.lang.ClassLoader.loadClass(ClassLoader.java:424)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.lang.ClassLoader.loadClass(ClassLoader.java:357)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.lang.Class.forName0(Native Method)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.lang.Class.forName(Class.java:348)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8195)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:54)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1613)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.readExternal(CacheContinuousQueryHandler.java:1077)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1840)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1799)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
2016-03-04T15:08:24.259Z rms01-t01-rcs01.lab.nordigy.ru ERR cas at
Re: Semaphore waiting for permit even if node is shut down
Vladislav,
I provided my thoughts in the ticket. Please take a look.
-Val
On Mon, Feb 29, 2016 at 8:46 AM, Vladisav Jelisavcic
wrote:
> Sure, no problem.
>
> I created a ticket:
> https://issues.apache.org/jira/browse/IGNITE-2735
>
> and a PR to resolve this problem.
> I think this should also fix: IGNITE-1977
> but the non-failover test scenario is not good anymore;
>
> Best regards,
> Vladisav
>
>
>
>
> On Mon, Feb 29, 2016 at 2:32 PM, Vladimir Ozerov
> wrote:
>
> > Hi,
> >
> > I tested your code in multi-node scenario, and semaphore is released fine
> > when node owning a permit has been closed. In your code sample there is
> > only one node, and in this case semaphore is not released. I think that
> > "acquire" method should throw an exception in this case (say,
> > InterruptedException) as semaphore is no longer accessible when node is
> > stopped.
> >
> > Vladislav,
> > I know you worked on distributed semaphore. Could you please share your
> > thoughts on the matter? And would you mind fixing that for a single-node
> > scenario?
> >
> > Vladimir.
> >
> > On Sun, Feb 28, 2016 at 11:14 PM, nyname00
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > I've got a problem with a semaphore that seems to wait for a permit
> even
> > if
> > > the node is already shut down. This behavior appears in a multi-node
> > setup
> > > where i try to shut down all nodes at the same time (using a
> > poison-pill).
> > > The code below can be used to reproduce the behavior. You will notice
> > that
> > > there is no call on sem1#release() - this is because in my poison-pill
> > > scenario there seems to be no way to get a handle to sem1. And since I
> > was
> > > under the impression that any semaphore gets released by Ignite when
> the
> > > node crashes/is shut down, I was expecting an exception on
> > sem2#acquire().
> > >
> > > Any ideas? Best regards,
> > > Mario
> > >
> > > public static void main(String[] args) {
> > > Ignite i1 = Ignition.start(new
> > > IgniteConfiguration().setGridName("1"));
> > >
> > > System.out.println(">>> I1 STARTED");
> > > IgniteSemaphore sem1 = i1.semaphore("sem1", 1, true, true);
> > > System.out.println(">>> S1 READ");
> > > sem1.acquire();
> > > System.out.println(">>> S1 ACQUIRED");
> > >
> > > new Thread(() -> {
> > > IgniteSemaphore sem2 = i1.semaphore("sem1", 1, true, true);
> > > System.out.println(">>> S1 READ 2");
> > > sem2.acquire();
> > > try {
> > > System.out.println(">>> S1 ACQUIRED 2");
> > > } finally {
> > > sem2.release();
> > > }
> > > }).start();
> > >
> > > try {
> > > TimeUnit.SECONDS.sleep(2);
> > > } catch (InterruptedException e) {
> > > e.printStackTrace();
> > > }
> > >
> > > System.out.println(">>> I1 CLOSING");
> > > i1.close();
> > > System.out.println(">>> I1 CLOSED");
> > > }
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://apache-ignite-users.70518.x6.nabble.com/Semaphore-waiting-for-permit-even-if-node-is-shut-down-tp3232.html
> > > Sent from the Apache Ignite Users mailing list archive at Nabble.com.
> > >
> >
>
Re: Switching back to review-then-commit process
It saddens me to see this coming to it ;( On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: > Igniters, > > I would propose to switch back to review-then-commit process. This > process has to be followed by both contributors and committers. > > There is a reason for this I have in mind. Ignite is a complex > platform with several big modules. Some of the people may be experts > in module A while others in module B etc. > If a committer, who is good in module A, makes changes in module B > merging the changes without a review this can break module's B > internal functionality that the committer didn't take into account. > > My proposal is to introduce a list of maintainers for every Ignite > module like it's done in Spark [1] and a rule that will require a > committer to get an approval from a module maintainer before merging > changes. > > Thoughts? > > -- > Denis > > [1] > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers > > > signature.asc Description: Digital signature
[jira] [Created] (IGNITE-2766) Cache instance is closed when client disconnects
Valentin Kulichenko created IGNITE-2766: --- Summary: Cache instance is closed when client disconnects Key: IGNITE-2766 URL: https://issues.apache.org/jira/browse/IGNITE-2766 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Valentin Kulichenko Fix For: 1.6 In case client disconnects and reconnects after network timeout (i.e., with a new ID), all cache instances acquired by this client are closed and are not functional. User has to create a special logic to handle this case. Cache proxy should be able to handle this automatically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
Valentin Kulichenko created IGNITE-2765:
---
Summary: WebSessionFilter doesn't survive client reconnect
Key: IGNITE-2765
URL: https://issues.apache.org/jira/browse/IGNITE-2765
Project: Ignite
Issue Type: Bug
Components: websession
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
If a {{WebSessionFilter}} is started with an embedded client, it is not
functional after the client disconnects and reconnects. Any operation throws
the exception below.
{noformat}
java.lang.IllegalStateException: Cache has been closed or destroyed: WebCache
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:160)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1958)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:855)
at
org.apache.ignite.cache.websession.WebSessionFilter.doFilter0(WebSessionFilter.java:341)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2764) LINQ plan caching
Pavel Tupitsyn created IGNITE-2764: -- Summary: LINQ plan caching Key: IGNITE-2764 URL: https://issues.apache.org/jira/browse/IGNITE-2764 Project: Ignite Issue Type: Sub-task Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.6 Investigate EF/NHibernate: how do they calculate cache key from expression tree to cache query plan? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] ignite pull request: ignite-2757 Test fixed
Github user agura closed the pull request at: https://github.com/apache/ignite/pull/535 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Contributions that are waiting for review
Pavel, I think that script should be stored inside TeamCity task. On Fri, Mar 4, 2016 at 3:56 PM, Pavel Tupitsyn wrote: > Anton, good idea, the script can be stored in git this way. Dmitriy, what > do you think? > > Another question is the email account to send from. Do we have something > suitable already? > > > > On Fri, Mar 4, 2016 at 3:34 PM, Anton Vinogradov > > wrote: > > > Folks, > > > > we can create TeamCity task with special trigger (eg. once a day). > > This task can contains any script. > > > > On Fri, Mar 4, 2016 at 3:18 PM, Pavel Tupitsyn > > wrote: > > > > > Raul, I'm not good with shell scripts. As a .net person I was thinking > > > about a scheduled C# script on one of our TeamCity win machines, but > > Dmitry > > > prefers Jenkins. > > > > > > > > > On Fri, Mar 4, 2016 at 2:52 PM, Raul Kripalani > wrote: > > > > > > > I believe all we need is a shell script in our source tree that > queries > > > the > > > > JIRA API and produces an output on stdout. > > > > > > > > We can then schedule an overnight job with, e.g. a 0 23 * * * cron > > > > expression, and configure the output to be sent to the ML, as > indicated > > > > here: https://wiki.apache.org/general/Jenkins. > > > > > > > > @Pavel, would you like to work on the shell script? I can help you > > > > configure the JKS job. > > > > > > > > @Dmitriy, can you add both Pavel and me as job admins? > > > > > > > > > > > > > > https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson#How_do_I_get_an_account > > > > > > > > Cheers, > > > > > > > > > >
Re: Contributions that are waiting for review
Anton, good idea, the script can be stored in git this way. Dmitriy, what do you think? Another question is the email account to send from. Do we have something suitable already? On Fri, Mar 4, 2016 at 3:34 PM, Anton Vinogradov wrote: > Folks, > > we can create TeamCity task with special trigger (eg. once a day). > This task can contains any script. > > On Fri, Mar 4, 2016 at 3:18 PM, Pavel Tupitsyn > wrote: > > > Raul, I'm not good with shell scripts. As a .net person I was thinking > > about a scheduled C# script on one of our TeamCity win machines, but > Dmitry > > prefers Jenkins. > > > > > > On Fri, Mar 4, 2016 at 2:52 PM, Raul Kripalani wrote: > > > > > I believe all we need is a shell script in our source tree that queries > > the > > > JIRA API and produces an output on stdout. > > > > > > We can then schedule an overnight job with, e.g. a 0 23 * * * cron > > > expression, and configure the output to be sent to the ML, as indicated > > > here: https://wiki.apache.org/general/Jenkins. > > > > > > @Pavel, would you like to work on the shell script? I can help you > > > configure the JKS job. > > > > > > @Dmitriy, can you add both Pavel and me as job admins? > > > > > > > > > https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson#How_do_I_get_an_account > > > > > > Cheers, > > > > > >
Re: Contributions that are waiting for review
Folks, we can create TeamCity task with special trigger (eg. once a day). This task can contains any script. On Fri, Mar 4, 2016 at 3:18 PM, Pavel Tupitsyn wrote: > Raul, I'm not good with shell scripts. As a .net person I was thinking > about a scheduled C# script on one of our TeamCity win machines, but Dmitry > prefers Jenkins. > > > On Fri, Mar 4, 2016 at 2:52 PM, Raul Kripalani wrote: > > > I believe all we need is a shell script in our source tree that queries > the > > JIRA API and produces an output on stdout. > > > > We can then schedule an overnight job with, e.g. a 0 23 * * * cron > > expression, and configure the output to be sent to the ML, as indicated > > here: https://wiki.apache.org/general/Jenkins. > > > > @Pavel, would you like to work on the shell script? I can help you > > configure the JKS job. > > > > @Dmitriy, can you add both Pavel and me as job admins? > > > > > https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson#How_do_I_get_an_account > > > > Cheers, > > >
Re: Contributions that are waiting for review
Raul, I'm not good with shell scripts. As a .net person I was thinking about a scheduled C# script on one of our TeamCity win machines, but Dmitry prefers Jenkins. On Fri, Mar 4, 2016 at 2:52 PM, Raul Kripalani wrote: > I believe all we need is a shell script in our source tree that queries the > JIRA API and produces an output on stdout. > > We can then schedule an overnight job with, e.g. a 0 23 * * * cron > expression, and configure the output to be sent to the ML, as indicated > here: https://wiki.apache.org/general/Jenkins. > > @Pavel, would you like to work on the shell script? I can help you > configure the JKS job. > > @Dmitriy, can you add both Pavel and me as job admins? > > https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson#How_do_I_get_an_account > > Cheers, >
Re: Contributions that are waiting for review
I believe all we need is a shell script in our source tree that queries the JIRA API and produces an output on stdout. We can then schedule an overnight job with, e.g. a 0 23 * * * cron expression, and configure the output to be sent to the ML, as indicated here: https://wiki.apache.org/general/Jenkins. @Pavel, would you like to work on the shell script? I can help you configure the JKS job. @Dmitriy, can you add both Pavel and me as job admins? https://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson#How_do_I_get_an_account Cheers,
[GitHub] ignite pull request: Ignite 2763
GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/538 Ignite 2763 You can merge this pull request into a Git repository by running: $ git pull https://github.com/dkarachentsev/ignite ignite-2763 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/538.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #538 commit 946dccb9e98419bf9921b12607667d74ef87ecda Author: dkarachentsev Date: 2016-02-10T08:33:04Z IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration. commit 3d5999821d0efd6c026adbb3256c86bc798dc1c7 Author: dkarachentsev Date: 2016-02-10T08:50:09Z Merge remote-tracking branch 'upstream/master' commit 375eb11ba8c9076906971785fdb7bead294d8022 Author: dkarachentsev Date: 2016-02-11T09:47:18Z Merge remote-tracking branch 'upstream/master' commit 88a11b4554884acd2dbd956fcbd37a8932fbde8e Author: dkarachentsev Date: 2016-02-12T08:39:32Z Merge remote-tracking branch 'upstream/master' commit d5f0cc8034fbbe6c34e1061fb7171e9574307413 Author: dkarachentsev Date: 2016-02-15T08:24:15Z IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration. Delete method commit 38a8d6c1d060f5fc120579fe4b348741a30b4a05 Author: dkarachentsev Date: 2016-02-15T08:26:58Z IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration. Delete method commit 7363051446ef571c1c814719b92ee7ce0b4706c4 Author: dkarachentsev Date: 2016-02-16T10:02:03Z Merge remote-tracking branch 'upstream/master' commit 3523de2a3bdfbb8fcf7a70e3a7be262577d32fce Author: dkarachentsev Date: 2016-02-17T07:35:12Z Merge remote-tracking branch 'upstream/master' commit 92d856183d8e72df87d628a88baeeb7c3d56624e Author: dkarachentsev Date: 2016-02-19T12:40:06Z Merge remote-tracking branch 'upstream/master' commit b4b251135a4cacf2b1e1f4c00bc2766a2dced681 Author: dkarachentsev Date: 2016-02-20T07:26:18Z Merge remote-tracking branch 'upstream/master' commit 301ab3e49ea4b20692d54ff3de2476ad6bf2b10e Author: dkarachentsev Date: 2016-02-25T07:15:09Z Merge remote-tracking branch 'upstream/master' commit fed76e91927a867571054230d99182867a6b1206 Author: dkarachentsev Date: 2016-02-26T10:05:25Z Merge remote-tracking branch 'upstream/master' commit 0122e48e2d6d84cf608883a6946f8eefff516d3b Author: dkarachentsev Date: 2016-03-01T12:19:37Z Merge remote-tracking branch 'upstream/master' commit 02c7ef877ec1bc620f716df57a72ba9bd8c6b369 Author: dkarachentsev Date: 2016-03-03T08:13:34Z Merge remote-tracking branch 'upstream/master' commit f039520d8166088f421c9808a00478220b85ad42 Author: dkarachentsev Date: 2016-03-04T10:25:50Z Merge remote-tracking branch 'upstream/master' commit fadd9727ae6fadbf7c77a6af7ce2971509da7069 Author: dkarachentsev Date: 2016-03-04T10:28:15Z IGNITE-2763 - GridDhtPartitionDemander fails with assertion on partition move --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-2763) GridDhtPartitionDemander fails with assertion on partition move
Dmitry Karachentsev created IGNITE-2763: --- Summary: GridDhtPartitionDemander fails with assertion on partition move Key: IGNITE-2763 URL: https://issues.apache.org/jira/browse/IGNITE-2763 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Dmitry Karachentsev Fix For: 1.6 When starts single node and is filled with cache items, then are started three new nodes GridDhtPartitionDemander fails with assertion error. java.lang.AssertionError: Partition already done [cache=cache_name, fromNode=1073a1d0-5139-44d3-9dee-399637bfd001, part=0, left=[2, 259, 771, 5, 6, 518, 774, 263, 775, 780, 271, 275, 540, 797, 30, 32, 802, 547, 807, 810, 556, 45, 301, 813, 302, 305, 561, 55, 312, 57, 59, 575, 324, 327, 331, 336, 594, 597, 598, 88, 859, 605, 606, 353, 867, 357, 871, 873, 363, 875, 371, 631, 887, 383, 640, 896, 898, 899, 644, 900, 646, 903, 905, 652, 908, 653, 912, 660, 662, 919, 153, 419, 422, 934, 172, 173, 429, 941, 176, 177, 180, 694, 953, 955, 445, 957, 959, 448, 451, 707, 199, 201, 972, 205, 718, 974, 207, 208, 721, 725, 471, 728, 985, 986, 475, 987, 477, 478, 225, 230, 233, 747, 237, 750, 497, 756, 503, 505, 1018, 1019, 764, 510, 1022]] at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:978) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1100(GridDhtPartitionDemander.java:751) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:600) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:408) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:605) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:303) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$400(GridCacheIoManager.java:81) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1108) at org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2239) at org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1004) at org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103) at org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:973) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: distributed data types for ML applications
This sounds excellent, I'll get right to it. Best regards, Vladisav On Fri, Mar 4, 2016 at 2:48 AM, Dmitriy Setrakyan wrote: > Vladislav, > > This would be a great contribution. For a feature like this, I would pick 1 > ML library and propose the design first. Once the community agrees on the > design, you can proceed with the implementation. > > Does this sound good? > > D. > > On Thu, Mar 3, 2016 at 11:22 AM, Vladisav Jelisavcic > wrote: > > > Igniters, > > > > is IGNITE-1251 still a thing? > > If so, I would really like to start working on this one. > > > > Best regards, > > Vladisav > > >
[jira] [Created] (IGNITE-2762) Optimized composite striped RW lock to avoid TLS lookups.
Vladimir Ozerov created IGNITE-2762:
---
Summary: Optimized composite striped RW lock to avoid TLS lookups.
Key: IGNITE-2762
URL: https://issues.apache.org/jira/browse/IGNITE-2762
Project: Ignite
Issue Type: Sub-task
Components: general
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 1.6
Currently {{StripedCompositeReadWriteLock}} relies on thread-local index to
find-out thread index.
As these locks are usually used inside IgniteThread, we can assign special
index to each thread instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] ignite pull request: IGNITE-2562 fixed bs-affix behavior
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/461 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request: IGNITE-2253 refactoring clusters page
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/411 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request: IGNTIE-2723 fixed java class input
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/532 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request: IGNITE-2597 added socket support
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/481 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request: IGNITE-2369 added ability to auto close popup...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/465 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request: IGNITE-2451 remove xml and java data render f...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/457 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-2761) Optimized "daemon" node flag lookup for TcpDiscoveryNode.
Vladimir Ozerov created IGNITE-2761: --- Summary: Optimized "daemon" node flag lookup for TcpDiscoveryNode. Key: IGNITE-2761 URL: https://issues.apache.org/jira/browse/IGNITE-2761 Project: Ignite Issue Type: Sub-task Components: general Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.6 Currently we perform lookup to attrs map on every call. There is no need for this. Instead, we should do that only once and then cache value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2760) Optimize reservation logic in GridAbstractCommunicationClient.
Vladimir Ozerov created IGNITE-2760: --- Summary: Optimize reservation logic in GridAbstractCommunicationClient. Key: IGNITE-2760 URL: https://issues.apache.org/jira/browse/IGNITE-2760 Project: Ignite Issue Type: Sub-task Components: general Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.6 It can be easily rewritten to wait-free non-blocking algorithm with help of increment/decrement methods. Should be a bit faster than existing implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2759) Cache conflicts must honour "keepBinary" flag.
Vladimir Ozerov created IGNITE-2759:
---
Summary: Cache conflicts must honour "keepBinary" flag.
Key: IGNITE-2759
URL: https://issues.apache.org/jira/browse/IGNITE-2759
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Dmitry Karachentsev
Priority: Critical
Fix For: 1.6
*Problem*
{{GridCacheMapEntry}} deals with conflicts in some methods like {{innerSet}}.
{{innerUpdate}}, etc.. When conflict occurs, we always deserialize keys/values
what could lead to exceptions if there are no classes on the server.
*Solution*
Deserialize keys/values only if "keepBinary=false".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
