Re: ContinuousQuery onUpdate

[Alexey Goncharuk]

Replied in the ticket.​

[jira] [Created] (IGNITE-3429) org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-3429:
---

 Summary: org.hibernate.cache.spi.CacheKey not properly serialized 
by binary marshaller
 Key: IGNITE-3429
 URL: https://issues.apache.org/jira/browse/IGNITE-3429
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.6
Reporter: Valentin Kulichenko
 Fix For: 1.7


{{org.hibernate.cache.spi.CacheKey}} is a class used as a key for all entries 
in the Hibernate L2 cache. This class contains {{type}} field and custom 
{{equals}} logic where the type is used as a helper and does not participate in 
comparison. Instances of the same type are producing different hash codes in 
different JVMs, which actually breaks comparison when binary format is used, 
where byte arrays are compared.

The issue is described in more detail here: 
http://stackoverflow.com/questions/38132263/apache-ignite-as-hibernate-l2-cache-storing-duplicate-entities



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Ignite 3227

[Dmitriy Setrakyan]

I think we should add only 1 new method:

long sizeLong(int partId, CachePeekMode peekMode)

D.

On Tue, Jul 5, 2016 at 3:24 PM, Alexander Paschenko <
alexander.a.pasche...@gmail.com> wrote:

> Alexey in Jira
> https://issues.apache.org/jira/browse/IGNITE-3227?focusedCommentId=15360787
> suggested that we remove int sized methods from CacheProxy, and he has
> indeed removed them, but IgniteCache has such new methods too. Should
> we let them be or maybe it would be better to get rid of them? Please
> advise. Dmitriy Setrakyan, your opinion on the matter is of particular
> interest.
>
> 2016-07-04 19:30 GMT+03:00 Saikat Maitra :
> > Thanks a lot Alexey.
> >
> > Regards
> > Saikat
> >
> > On Mon, Jul 4, 2016 at 12:01 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> >> Saikat,
> >>
> >> Thanks for the contribution. I will make some minor changes to your
> patch
> >> and push it to master soon.
> >>
> >> 2016-06-26 9:57 GMT-07:00 Saikat Maitra :
> >>
> >> > Hi Alexey, Ilya
> >> >
> >> > As discussed I have made the changes in the PR[1]. Please review and
> let
> >> me
> >> > know any feedback.
> >> >
> >> > [1] https://github.com/apache/ignite/pull/815
> >> > [2] https://issues.apache.org/jira/browse/IGNITE-3227
> >> >
> >> >
> >> > Regards
> >> > Saikat
> >> >
> >> > On Mon, Jun 20, 2016 at 10:40 PM, Saikat Maitra <
> saikat.mai...@gmail.com
> >> >
> >> > wrote:
> >> >
> >> > > Sure Alexey,
> >> > >
> >> > > Thank you
> >> > > Saikat
> >> > >
> >> > > On Mon, Jun 20, 2016 at 10:36 PM, Alexey Goncharuk <
> >> > > alexey.goncha...@gmail.com> wrote:
> >> > >
> >> > >> Saikat,
> >> > >>
> >> > >> Please also correct the test to check new methods for PARTITIONED
> and
> >> > >> REPLICATED cache - I see that you only test them for local cache
> and
> >> > >> partition 0 (I added a comment to the ticket).
> >> > >>
> >> > >> 2016-06-20 9:17 GMT-07:00 Saikat Maitra :
> >> > >>
> >> > >> > Thank you Ilya, I will review and update PR accordingly.
> >> > >> >
> >> > >> > Regards
> >> > >> > Saikat
> >> > >> >
> >> > >> > On Mon, Jun 20, 2016 at 8:36 PM, Ilya Lantukh <
> >> ilant...@gridgain.com>
> >> > >> > wrote:
> >> > >> >
> >> > >> > > Hi Saikat,
> >> > >> > >
> >> > >> > > I've added a comment to the jira ticket regarding
> implementation
> >> of
> >> > >> > > GridCacheAdapter#localSizeLong(int partition, CachePeekMode[]
> >> > >> peekModes)
> >> > >> > > method.
> >> > >> > >
> >> > >> > > On Sat, Jun 18, 2016 at 12:19 PM, Saikat Maitra <
> >> > >> saikat.mai...@gmail.com
> >> > >> > >
> >> > >> > > wrote:
> >> > >> > >
> >> > >> > > > Hi
> >> > >> > > >
> >> > >> > > > I have raised the PR[1] for the jira ticket Ignite 3227 [2]
> and
> >> > >> wanted
> >> > >> > to
> >> > >> > > > discuss further on this issue.
> >> > >> > > >
> >> > >> > > > 1. I am running 2 nodes cluster and running in client mode
> >> another
> >> > >> node
> >> > >> > > for
> >> > >> > > > functional test. I added 20 keys and keys are distributed in
> 2
> >> > >> nodes as
> >> > >> > > 11
> >> > >> > > > keys in node 1 and 9 keys in node 2. When I am printing
> >> partition
> >> > 1
> >> > >> > size
> >> > >> > > > and partition 2 size I can get correct values but incase I
> >> provide
> >> > >> some
> >> > >> > > > other partition like 5 I am observing that I am getting 11 as
> >> > value.
> >> > >> > > >
> >> > >> > > > 2. I have added unit test testpartitionsize() similar to
> >> > testSize()
> >> > >> but
> >> > >> > > > similar tests are failing for both the tests. Need further
> >> > >> > investigation
> >> > >> > > on
> >> > >> > > > the same.
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > Regards
> >> > >> > > > Saikat
> >> > >> > > >
> >> > >> > > > [1] https://github.com/apache/ignite/pull/815
> >> > >> > > > [2] https://issues.apache.org/jira/browse/IGNITE-3227
> >> > >> > > >
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > --
> >> > >> > > Best regards,
> >> > >> > > Ilya
> >> > >> > >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> >
> >>
>

Re: Ignite & Kubernetes

[Paulo Pires]

Sorry for the delay. Sure! Need guidance, though. I'll ping you on gitter.
On Jun 28, 2016 20:18, "Dmitriy Setrakyan"  wrote:

> Paulo, would you like to contribute this to Ignite?
>
> On Tue, Jun 28, 2016 at 11:43 AM, Paulo Pires  wrote:
>
>> I came up with
>> https://github.com/pires/apache-ignite-discovery-kubernetes.
>>
>> I have been using this in production Kubernetes. Obviously, one needs DNS
>> integration which happens to be a best-practice anyway.
>>
>> Pires
>>
>> On Thu, Apr 28, 2016 at 4:45 PM Dmitriy Setrakyan 
>> wrote:
>>
>>> Ignite does not have any specific Kubernetes integration, however, if it
>>> supports TCP/IP, which I am pretty sure it does, then we can easily do
>>> auto-discovery there using our static IP discovery:
>>>
>>>
>>> https://apacheignite.readme.io/docs/cluster-config#static-ip-based-discovery
>>>
>>> Also, it is likely that it will work smoothly with Ignite docker
>>> container:
>>> https://ignite.apache.org/download.cgi#docker
>>>
>>> D.
>>>
>>> On Thu, Apr 28, 2016 at 6:50 AM, Christos Erotocritou <
>>> chris...@gridgain.com> wrote:
>>>
 Hi all,

 Is anyone working with Ignite & kubernetes?

 Moreover I’d like to understand how it would be possible to do auto
 discovery of new Ignite nodes.

 Thanks,

 Christos
>>>
>>>
>>>
>

Re: Ignite 3227

[Alexander Paschenko]

Alexey in Jira 
https://issues.apache.org/jira/browse/IGNITE-3227?focusedCommentId=15360787
suggested that we remove int sized methods from CacheProxy, and he has
indeed removed them, but IgniteCache has such new methods too. Should
we let them be or maybe it would be better to get rid of them? Please
advise. Dmitriy Setrakyan, your opinion on the matter is of particular
interest.

2016-07-04 19:30 GMT+03:00 Saikat Maitra :
> Thanks a lot Alexey.
>
> Regards
> Saikat
>
> On Mon, Jul 4, 2016 at 12:01 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Saikat,
>>
>> Thanks for the contribution. I will make some minor changes to your patch
>> and push it to master soon.
>>
>> 2016-06-26 9:57 GMT-07:00 Saikat Maitra :
>>
>> > Hi Alexey, Ilya
>> >
>> > As discussed I have made the changes in the PR[1]. Please review and let
>> me
>> > know any feedback.
>> >
>> > [1] https://github.com/apache/ignite/pull/815
>> > [2] https://issues.apache.org/jira/browse/IGNITE-3227
>> >
>> >
>> > Regards
>> > Saikat
>> >
>> > On Mon, Jun 20, 2016 at 10:40 PM, Saikat Maitra > >
>> > wrote:
>> >
>> > > Sure Alexey,
>> > >
>> > > Thank you
>> > > Saikat
>> > >
>> > > On Mon, Jun 20, 2016 at 10:36 PM, Alexey Goncharuk <
>> > > alexey.goncha...@gmail.com> wrote:
>> > >
>> > >> Saikat,
>> > >>
>> > >> Please also correct the test to check new methods for PARTITIONED and
>> > >> REPLICATED cache - I see that you only test them for local cache and
>> > >> partition 0 (I added a comment to the ticket).
>> > >>
>> > >> 2016-06-20 9:17 GMT-07:00 Saikat Maitra :
>> > >>
>> > >> > Thank you Ilya, I will review and update PR accordingly.
>> > >> >
>> > >> > Regards
>> > >> > Saikat
>> > >> >
>> > >> > On Mon, Jun 20, 2016 at 8:36 PM, Ilya Lantukh <
>> ilant...@gridgain.com>
>> > >> > wrote:
>> > >> >
>> > >> > > Hi Saikat,
>> > >> > >
>> > >> > > I've added a comment to the jira ticket regarding implementation
>> of
>> > >> > > GridCacheAdapter#localSizeLong(int partition, CachePeekMode[]
>> > >> peekModes)
>> > >> > > method.
>> > >> > >
>> > >> > > On Sat, Jun 18, 2016 at 12:19 PM, Saikat Maitra <
>> > >> saikat.mai...@gmail.com
>> > >> > >
>> > >> > > wrote:
>> > >> > >
>> > >> > > > Hi
>> > >> > > >
>> > >> > > > I have raised the PR[1] for the jira ticket Ignite 3227 [2] and
>> > >> wanted
>> > >> > to
>> > >> > > > discuss further on this issue.
>> > >> > > >
>> > >> > > > 1. I am running 2 nodes cluster and running in client mode
>> another
>> > >> node
>> > >> > > for
>> > >> > > > functional test. I added 20 keys and keys are distributed in 2
>> > >> nodes as
>> > >> > > 11
>> > >> > > > keys in node 1 and 9 keys in node 2. When I am printing
>> partition
>> > 1
>> > >> > size
>> > >> > > > and partition 2 size I can get correct values but incase I
>> provide
>> > >> some
>> > >> > > > other partition like 5 I am observing that I am getting 11 as
>> > value.
>> > >> > > >
>> > >> > > > 2. I have added unit test testpartitionsize() similar to
>> > testSize()
>> > >> but
>> > >> > > > similar tests are failing for both the tests. Need further
>> > >> > investigation
>> > >> > > on
>> > >> > > > the same.
>> > >> > > >
>> > >> > > >
>> > >> > > > Regards
>> > >> > > > Saikat
>> > >> > > >
>> > >> > > > [1] https://github.com/apache/ignite/pull/815
>> > >> > > > [2] https://issues.apache.org/jira/browse/IGNITE-3227
>> > >> > > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > --
>> > >> > > Best regards,
>> > >> > > Ilya
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>

Re: Compilation failure on fresh clone

[NoTrueScotsman]

Hi Andrey, thanks for this.

On Tue, Jul 5, 2016 at 1:21 PM, Andrey Novikov  wrote:
> Hi NoTrueScotsman,
>
> Compilation failed only under java 8. CI used java 7 for tests.
>
> Fixed compilation error in master.
>
> On Tue, Jul 5, 2016 at 3:52 PM, NoTrueScotsman 
> wrote:
>
>> Hi all, I just tried to compile a fresh clone off master branch[1] and
>> getting a compilation failure:
>>
>> $ mvn clean package -DskipTests
>> ...
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile
>> (default-testCompile) on project ignite-clients: Compilation failure
>> [ERROR]
>>
>> /Users/jhoffmann/Development/apache-ignite/modules/clients/src/test/java/org/apache/ignite/internal/client/integration/ClientAbstractSelfTest.java:[505,9]
>> reference to assertEquals is ambiguous
>> [ERROR] both method assertEquals(java.lang.Object,java.lang.Object) in
>> junit.framework.TestCase and method assertEquals(int,int) in
>> junit.framework.TestCase match
>>
>>
>> While fairly easy to fix locally, I'm wondering how can it get past CI?
>>
>> It was apparently fixed in a recent commit[2], but then undone again in the
>> subsequent commit[3].
>>
>> Am I doing something wrong or should I raise a bug for it?
>>
>> Cheers
>> Jens
>>
>> [1] https://github.com/apache/ignite
>> [2]
>>
>> https://github.com/apache/ignite/commit/c60fcafc2c73d6ca52a9e60677980ae97a1f8505
>> [3]
>>
>> https://github.com/apache/ignite/commit/40d863246dab99c34d215a47eb6598e285e1a7f7
>>

[jira] [Created] (IGNITE-3428) TcpCommunicationSpi: potential message lost during reconnect

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-3428:


 Summary: TcpCommunicationSpi: potential message lost during 
reconnect
 Key: IGNITE-3428
 URL: https://issues.apache.org/jira/browse/IGNITE-3428
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Semen Boikov
Priority: Critical


Added test reproducing lost message during reconnect: 
IgniteCacheMessageRecoveryIdleConnection. 

It is possible that method 'send' finished, then connection closed, there are 
unacknowledged messages, but communication does not try to reconnect (if there 
are no others messages to be sent to this node).

Looks like there are at least 2 issues:
- 'onDisconnected' checks result of 'clients.remove(id, rmv)' to trigger 
reconnect. this is not saf (e.g. client is removed when session is closed on 
idle timeout)
- 'onDisconnected' checks that messagesFutures() collection is not empty, but 
'onDisconnected' is erroneously called before all futures are polled from 
closing session (GridNioService.AbstractNioClientWorker.close)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request #848: IGNITE-3398 .NET: Allow extending predefined Affin...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/848


---
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 #852: ignite-3426: Compute Engine: job ID is generated i...

[dmagda]

GitHub user dmagda opened a pull request:

https://github.com/apache/ignite/pull/852

ignite-3426: Compute Engine: job ID is generated in a non unique way



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-3426

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/852.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 #852






---
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-3426) Compute Engine: job ID is generated in a non unique way

[Denis Magda (JIRA)]

Denis Magda created IGNITE-3426:
---

 Summary: Compute Engine: job ID is generated in a non unique way
 Key: IGNITE-3426
 URL: https://issues.apache.org/jira/browse/IGNITE-3426
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis Magda


Presently seems like new job IDs are generated in a way that is not guaranteed 
to be unique.

Specifically, job IDs are generated in: 
{code}
IgniteUuid jobId = IgniteUuid.fromUuid(node.id());
org/apache/ignite/internal/processors/task/GridTaskWorker.java:564)
{code}

fromUuid generates the new job ID using UUID passed to it + an AtomicInteger 
(who is always incremented). Since the UUID passed to it is the *destination 
node* and not the local node, in environments where the job submission is 
relatively even, the generated job ID might not be unique.

Think that the UUID used there is supposed to be the local node UUID.

Otherwise this can be a reason of the following exception

{noformat}
 "Jobs map already contains mapping for key" 
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Compilation failure on fresh clone

[Andrey Novikov]

Hi NoTrueScotsman,

Compilation failed only under java 8. CI used java 7 for tests.

Fixed compilation error in master.

On Tue, Jul 5, 2016 at 3:52 PM, NoTrueScotsman 
wrote:

> Hi all, I just tried to compile a fresh clone off master branch[1] and
> getting a compilation failure:
>
> $ mvn clean package -DskipTests
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile
> (default-testCompile) on project ignite-clients: Compilation failure
> [ERROR]
>
> /Users/jhoffmann/Development/apache-ignite/modules/clients/src/test/java/org/apache/ignite/internal/client/integration/ClientAbstractSelfTest.java:[505,9]
> reference to assertEquals is ambiguous
> [ERROR] both method assertEquals(java.lang.Object,java.lang.Object) in
> junit.framework.TestCase and method assertEquals(int,int) in
> junit.framework.TestCase match
>
>
> While fairly easy to fix locally, I'm wondering how can it get past CI?
>
> It was apparently fixed in a recent commit[2], but then undone again in the
> subsequent commit[3].
>
> Am I doing something wrong or should I raise a bug for it?
>
> Cheers
> Jens
>
> [1] https://github.com/apache/ignite
> [2]
>
> https://github.com/apache/ignite/commit/c60fcafc2c73d6ca52a9e60677980ae97a1f8505
> [3]
>
> https://github.com/apache/ignite/commit/40d863246dab99c34d215a47eb6598e285e1a7f7
>

[jira] [Created] (IGNITE-3425) Missed options in SQL editor.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3425:
-

 Summary: Missed options in SQL editor.
 Key: IGNITE-3425
 URL: https://issues.apache.org/jira/browse/IGNITE-3425
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Vasiliy Sisko


On opening of SQL notebook in log showed messages for every paragraph:

common.0bf89e8….js:12 misspelled option "enableSnippets"
common.0bf89e8….js:12 misspelled option "enableBasicAutocompletion"
common.0bf89e8….js:12 misspelled option "enableLiveAutocompletion"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3424) GridCacheQueryResponse is not registered in GridCacheIoManager

[Denis Magda (JIRA)]

Denis Magda created IGNITE-3424:
---

 Summary: GridCacheQueryResponse is not registered in 
GridCacheIoManager
 Key: IGNITE-3424
 URL: https://issues.apache.org/jira/browse/IGNITE-3424
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.6
Reporter: Denis Magda
 Fix For: 1.7


{{GridCacheQueryReponse}} is not fully registered in {{GridCacheIoManager}}. 

Sometimes this leads to the exceptions like this one

{noformat}
SEVERE: Failed to process message 
[senderId=ff6d12cc-e66d-4e29-8a91-ead5d9a7a570, messageType=class 
o.a.i.i.processors.cache.query.GridCacheQueryResponse]
class org.apache.ignite.IgniteCheckedException: Failed to send response to 
node. Unsupported direct type [message=GridCacheQueryResponse [finished=true, 
reqId=6, err=null, fields=false, metadata=null]]
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:567)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:278)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:80)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1085)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1058)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:104)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2295)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1018)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:104)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:987)
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)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to unmarshal 
object with optimized marshaller
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1044)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:275)
... 11 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to 
unmarshal object with optimized marshaller
at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1591)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1641)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:298)
at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal(BinaryMarshaller.java:112)
at 
org.apache.ignite.internal.processors.cache.GridCacheMessage.unmarshalCollection(GridCacheMessage.java:611)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.finishUnmarshal(GridCacheQueryResponse.java:152)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1038)
... 12 more
Caused by: class 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): 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader@54d8df0a
at 
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal(OptimizedMarshaller.java:225)
at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1588)
... 18 more
Caused by: java.lang.ClassNotFoundException: 
be.ing.tds.shielding.core.service.FileLoaderServiceImpl
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1702)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1547)
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.findClass(GridCacheDeploymentManager.java:858)
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.loadClass(GridCacheDeploymentManager.java:815)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8263)
at 

[jira] [Created] (IGNITE-3423) Incorrect result of IgfsGlobalSpaceTask for unlimited IGFS

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3423:
-

 Summary: Incorrect result of IgfsGlobalSpaceTask for unlimited IGFS
 Key: IGNITE-3423
 URL: https://issues.apache.org/jira/browse/IGNITE-3423
 Project: Ignite
  Issue Type: Bug
  Components: IGFS
Affects Versions: 1.6
Reporter: Vasiliy Sisko


Expected that result will contain configured IGFS space limit or 0 when IGFS 
space is unlimited. 
Now for unlimited IGFS wrong value is returned. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3422) No way to control object initialization during deserialization/unmarshalling

[Denis Magda (JIRA)]

Denis Magda created IGNITE-3422:
---

 Summary: No way to control object initialization during 
deserialization/unmarshalling 
 Key: IGNITE-3422
 URL: https://issues.apache.org/jira/browse/IGNITE-3422
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.6
Reporter: Denis Magda


Presently there is no way to control instantiation of a {{BinaryObject}} that 
is being deserialized. The object is created using 
{{BinaryClassDescriptor#newInstance}} all the time.

It makes sense to add {{BinaryConfiguration.setInitializationFactory()}} method 
that will provide with such support.

Use case and details are provided in this discussion
http://apache-ignite-users.70518.x6.nabble.com/Properly-Immutable-Keys-values-with-Binary-objects-tp6082.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

ContinuousQuery onUpdate

[Andrey Velichko]

Hello, I need help about issue 
https://issues.apache.org/jira/browse/IGNITE-2079


If there are Exceptions inside notifyCallback0, client lose 
eventonUpdatefor ContinuousQuery.setLocalListener

see line 674 of CacheContinuousQueryHandler.notifyCallback0

It is common situation when listener handler fails and event lost for 
listener.

What the best way delivery Exception for listener?
Maybe it is unbelievable situation whencache.put passed and listener 
handler fails?

Compilation failure on fresh clone

[NoTrueScotsman]

Hi all, I just tried to compile a fresh clone off master branch[1] and
getting a compilation failure:

$ mvn clean package -DskipTests
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile
(default-testCompile) on project ignite-clients: Compilation failure
[ERROR]
/Users/jhoffmann/Development/apache-ignite/modules/clients/src/test/java/org/apache/ignite/internal/client/integration/ClientAbstractSelfTest.java:[505,9]
reference to assertEquals is ambiguous
[ERROR] both method assertEquals(java.lang.Object,java.lang.Object) in
junit.framework.TestCase and method assertEquals(int,int) in
junit.framework.TestCase match


While fairly easy to fix locally, I'm wondering how can it get past CI?

It was apparently fixed in a recent commit[2], but then undone again in the
subsequent commit[3].

Am I doing something wrong or should I raise a bug for it?

Cheers
Jens

[1] https://github.com/apache/ignite
[2]
https://github.com/apache/ignite/commit/c60fcafc2c73d6ca52a9e60677980ae97a1f8505
[3]
https://github.com/apache/ignite/commit/40d863246dab99c34d215a47eb6598e285e1a7f7