[jira] [Created] (IGNITE-2720) TcpDiscoveryMulticastIpFinder is not thread safe.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2720:
---

 Summary: TcpDiscoveryMulticastIpFinder is not thread safe.
 Key: IGNITE-2720
 URL: https://issues.apache.org/jira/browse/IGNITE-2720
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


*Problem*
TcpDiscoveryMulticastIpFinder contains several  non-thread-safe collections. 
E.g. {{reqItfs}} which is a {{HashSet}}.
And these collections could be accessed from different thread concurrently. 
E.g., mentioned collection can be accessed from the following methods:
1) {{initializeLocalAddresses}} (invoked from {{spiStart}}) - this is already a 
problem for shared IP finder in case two nodes start in the same JVM.
2) {{getRegisteredAddresses}} - accessed from billion places including client 
reconnect routine. 

As a result we could receive things like that:
{code}
java.util.ConcurrentModificationException
 at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
 at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
 at 
org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder.requestAddresses(TcpDiscoveryMulticastIpFinder.java:475)
 at 
org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder.getRegisteredAddresses(TcpDiscoveryMulticastIpFinder.java:431)
 at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
 at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
 at 
org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
 at 
org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
 at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.tryJoin(ClientImpl.java:1509)
 at 
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1328)
 at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}

*Solution*
Investigate access patterns and make multicast IP finder thread-safe. Porbably 
we have similar problems in other IP finders - need to check that.



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

[GitHub] ignite pull request: Ignite-2709 - Fixed stack overflow for conten...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2707 - Fixed skipStore flag handling.

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2719) Value is not copied in entry processor if optimized marshaller is used

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2719:
---

 Summary: Value is not copied in entry processor if optimized 
marshaller is used
 Key: IGNITE-2719
 URL: https://issues.apache.org/jira/browse/IGNITE-2719
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Blocker
 Fix For: 1.6


If {{OptimizedMarshaller}} is used, the {{MutableEntry}} passed to entry 
processor contains the same instance that is stored in cache, even if 
{{copyOnRead}} flag is true.

This happens because {{CacheLazyEntry.getValue()}} method never creates a copy.

Test attached.



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

Re: CacheException in method signatures

[Dmitriy Setrakyan]

The way I understood, Yakov is talking about declaring an exception on the
method signature, no?

On Wed, Feb 24, 2016 at 2:54 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Yakov,
>
> I'm not sure I understand. What exactly you want to change and how it will
> fix the user's issue?
>
> -Val
>
> On Wed, Feb 24, 2016 at 2:21 AM, Yakov Zhdanov 
> wrote:
>
> > Guys,
> >
> > Please take a look at stacktrace reported here -
> >
> >
> http://apache-ignite-users.70518.x6.nabble.com/Exception-on-Ignite-cluster-shutdown-td3129.html
> >
> > Here we have Cache.close() method throwing CacheException which is not
> > declared.
> >
> > Val, can you please review the signatures and fix issues of the kind?
> >
> > --Yakov
> >
>

Re: CacheException in method signatures

[Valentin Kulichenko]

Yakov,

I'm not sure I understand. What exactly you want to change and how it will
fix the user's issue?

-Val

On Wed, Feb 24, 2016 at 2:21 AM, Yakov Zhdanov  wrote:

> Guys,
>
> Please take a look at stacktrace reported here -
>
> http://apache-ignite-users.70518.x6.nabble.com/Exception-on-Ignite-cluster-shutdown-td3129.html
>
> Here we have Cache.close() method throwing CacheException which is not
> declared.
>
> Val, can you please review the signatures and fix issues of the kind?
>
> --Yakov
>

[jira] [Created] (IGNITE-2718) modules/zookeeper/target/libs directory does not have all dependencies

[Dustin Chesterman (JIRA)]

Dustin Chesterman created IGNITE-2718:
-

 Summary: modules/zookeeper/target/libs directory does not have all 
dependencies
 Key: IGNITE-2718
 URL: https://issues.apache.org/jira/browse/IGNITE-2718
 Project: Ignite
  Issue Type: Bug
  Components: build
Reporter: Dustin Chesterman
Priority: Critical


If you specify the zookeeper ip finder in the example cache config there are a 
host of classnotfound exceptions.  I believe these need to be populated into 
the build target lib dir.

{code}













{code}



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

Re: Apache Arrow and Apache Ignite

[Dood]

On 2/24/2016 1:31 PM, Konstantin Boudnik wrote:

On Sat, Feb 20, 2016 at 02:13PM, Dood@ODDO wrote:

That's the million dollar question - I think we should approach the
Arrow people and get a conversation going. We want to be ahead of
the curve, not behind it - Arrow seems to be making quite a stir,
not to mention that it was fast-tracked to mature project status
apparently solely based on the people/companies involved ;-)

I am afraid you misunderstand the point of the 'fast tracking'. To start with,
ASF doesn't case what companies are involved nor there's no such thing as fast
tracking. However, there's 'direct to TLP' track, that allows for a community
that has enough ASF members and other people, with lengthy involvement into
Apache projects, to go directly into TLP. The reason is simple: these people
are well versed in Apache Way and the incubation isn't required for me.

So, please stop using this 'fast-tracked' confusion.
   Cos

P.S. Another point: TLP != 'mature project status'. Please educate yourself
about the Apache incubation, before making statement like this in the future.



I will educate myself. What you need to do is learn to be polite. I am 
not sure you can teach that though ;(

Re: Apache Arrow and Apache Ignite

[Konstantin Boudnik]

On Sat, Feb 20, 2016 at 02:13PM, Dood@ODDO wrote:
> That's the million dollar question - I think we should approach the
> Arrow people and get a conversation going. We want to be ahead of
> the curve, not behind it - Arrow seems to be making quite a stir,
> not to mention that it was fast-tracked to mature project status
> apparently solely based on the people/companies involved ;-)

I am afraid you misunderstand the point of the 'fast tracking'. To start with,
ASF doesn't case what companies are involved nor there's no such thing as fast
tracking. However, there's 'direct to TLP' track, that allows for a community
that has enough ASF members and other people, with lengthy involvement into
Apache projects, to go directly into TLP. The reason is simple: these people
are well versed in Apache Way and the incubation isn't required for me.

So, please stop using this 'fast-tracked' confusion.
  Cos

P.S. Another point: TLP != 'mature project status'. Please educate yourself
about the Apache incubation, before making statement like this in the future.

> On 2/20/2016 11:14 AM, Dmitriy Setrakyan wrote:
> >It sounds to me that it does not store it’s own data, but allows to process
> >data from somewhere else, right? If yes, will I be able to take Ignite data
> >with Arrow and convert it to a columnar format for some other processing?
> >
> >On Sat, Feb 20, 2016 at 2:48 AM, Roman Shtykh 
> >wrote:
> >
> >>It's a standard (including format and algorithms) to share in-memory data
> >>between several big data platforms.
> >>In my understanding, it is like placing data in in-memory columns in
> >>Parquet and being able to use it in Kudu without serializing/deserializing.
> >>
> >>-Roman
> >>
> 


signature.asc
Description: Digital signature

[jira] [Created] (IGNITE-2717) Not active query execute and explane buttons in special case.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2717:
-

 Summary: Not active query execute and explane buttons in special 
case.
 Key: IGNITE-2717
 URL: https://issues.apache.org/jira/browse/IGNITE-2717
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


On replacing of all query text by Paste operation every second tyme execute and 
explane buttons are not active.



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

Re: Binary mode for Data Structures

[Dood]

IGNITE-1144 has been fixed so at least that obstacle is out of the way :-)

On 2/24/2016 9:10 AM, Denis Magda wrote:
The community has already faced with the issue that the binary mode is 
not supported for data structures.

https://issues.apache.org/jira/browse/IGNITE-2339

I've linked this ticket into IGNITE-2701.

--
Denis

On 2/23/2016 4:29 AM, Valentin Kulichenko wrote:
+1 to this change. It sounds like a very important feature for 
collocated

queues, especially after [1] is fixed.

[1] https://issues.apache.org/jira/browse/IGNITE-1144

-Val

On Sat, Feb 20, 2016 at 3:42 AM, Pavel Tupitsyn 
wrote:


No replies, so I've created an issue:
https://issues.apache.org/jira/browse/IGNITE-2701

On Thu, Feb 18, 2016 at 3:06 PM, Pavel Tupitsyn 


wrote:


Igniters,

Currently we don't have binary mode (withKeepBinary) in Data 
Structures

(Queue, AtomicReference).
Are there any plans for implementing this, or may be a workaround?

Lack of binary mode prevents us from implementing IgniteQueue in .NET
(.NET types in most cases can't be deserialized in Java).

AtomicReference is already implemented, and it works because values 
are

wrapped in GridCacheAtomicReferenceValue. So there is inconsistent

behavior

between data structures.

Thoughts?

--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com




--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

RE: Binary object inside Externalizable

[Andrey Kornev]

Val,

In our case, it's other way around -- use of Externalizable is pretty rare and 
it's mostly Serializables throughout the code base (not our code, but of our 
clients that use our software). Besides there are always those pesky 3d party 
libraries and the JDK itself (for example, the Throwable class) that use 
Serializable.

My point is that no matter how much we all love quick fixes, when it comes to 
serialization, all cases must be properly supported.

Regards
Andrey

> From: valentin.kuliche...@gmail.com
> Date: Tue, 23 Feb 2016 20:50:14 -0800
> Subject: Re: Binary object inside Externalizable
> To: dev@ignite.apache.org
> 
> Actually, adding Externalizable support to binary marshaller should not be
> difficult, no? BinaryWriterExImpl already implements ObjectOutput, so we
> just need to pass to writeExternal (and the same for deserialization). To
> be honest, I don't understand why we use optimized marshaller here and
> making this change should fix majority of use cases.
> 
> The issue will remain for writeObject/readObject which is much more
> complicated and where using optimized marshaller makes more sense. But this
> is a relatively rare case and I think we can fix this as a next step.
> 
> Thoughts?
> 
> On Sat, Feb 20, 2016 at 10:01 AM, Dmitriy Setrakyan 
> wrote:
> 
> > Andrey, you are absolutely right. I was suggesting a quick fix, which in my
> > view, would fix most of the issues. In the long term, we should fix the
> > binary serialization to work the way you are describing.
> >
> > D.
> >
> > On Sat, Feb 20, 2016 at 9:26 AM, Andrey Kornev 
> > wrote:
> >
> > > Val,
> > >
> > > I think Ignite Serialization should follow the approach similar to what
> > > Java serialization does: it can transparently and consistently handle
> > both
> > > Serializable and Externalizable classes. It can do it because it relies
> > on
> > > a single class - ObjectOutputStream - to do serialization (and a single
> > > class - ObjectInputStream - to do the opposite, but let's ignore it for
> > the
> > > moment). ObjectOutputStream delegates to proper user callbacks
> > (writeObject
> > > or writeExternal) at the right moments, but otherwise it fully controls
> > the
> > > on-the-wire representation and takes care of all the necessary stream
> > > framing/marking so that ObjectInputStream can then correctly deserialize
> > > the bytes. It's never a problem for Java to serialize an Externalizable
> > > field from a Serializable object and vice versa. Users can mix and match
> > > serialization APIs as they please.
> > >
> > > I think Ignite should just have a single marshaller, let's say the
> > Binary,
> > > which drives the whole serialization process. It doesn't delegate to
> > > OptimizedMarshaller as it does today. Instead it detects the
> > > Serializable/Externalizable classes and calls their serialization
> > callbacks
> > > - writeObject/writeExternal - passing in *itself* as
> > > ObjectOutputStream/ObjectOutput correspondingly. This way the entire
> > > serialization process never leaves the context of a single Binary
> > > marshaller and allows Ignite to handle such complex cases as the one
> > we're
> > > discussing now.
> > >
> > > I hope it makes sense.
> > >
> > > Andrey
> > >
> > > > From: valentin.kuliche...@gmail.com
> > > > Date: Fri, 19 Feb 2016 19:15:07 -0800
> > > > Subject: Binary object inside Externalizable
> > > > To: dev@ignite.apache.org
> > > >
> > > > Folks,
> > > >
> > > > I recently faced an issue which seems to be pretty critical. As you
> > know,
> > > > when binary marshaller meets an Externalizable object, it switches to
> > > > optimized marshaller. And if there is a regular object inside, it's
> > still
> > > > serialized with optimized, even if its type is declared in binary
> > > > configuration with custom mapper, etc. This looks wrong.
> > > >
> > > > It's getting even worse in compute grid, because closure processor
> > wraps
> > > > user's closures in some internal classes, which are Externalizable, so
> > > > these closures are always serialized with optimized marshaller.
> > > >
> > > > Does anyone have ideas on what is the proper fix for this?
> > > >
> > > > -Val
> > >
> > >
> >
  

[jira] [Created] (IGNITE-2715) HotSpot in GridQueryProcessor.BinaryProperty.value() method

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2715:
---

 Summary: HotSpot in GridQueryProcessor.BinaryProperty.value() 
method
 Key: IGNITE-2715
 URL: https://issues.apache.org/jira/browse/IGNITE-2715
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Denis Magda
Assignee: Vladimir Ozerov
Priority: Blocker
 Fix For: 1.6


The hotspot was detected in the following scenario.

1) Start a server node(s) with CacheConfiguration that stores binary objects of 
type T and has field A in the indexes;

2) Start client node that creates objects of type T using BinaryObjectBuilder 
but doesn't set value for field A at all;

3) Client populates the cache with created objects using IgniteDataStreamer at 
high rate.

If you connect to the server using Visual VM you'll see that threads from the 
public thread pull spend a lot of time waiting for a monitor and that 
{{GridQueryProcessor.BinaryProperty.value()}} is a hotspot.

The reason why the method above is the hotspot is because it calls 
{{U.warn(log, "Neither key nor value have property " +
"[propName=" + propName + ", key=" + key + ", val=" 
+ val + "]");}}

all the time converting a binary object to String. The warning is called 
because field A is not set in the binary representation.

This warning must be reworked in one of the following way:
- just print the name of the field that is not found;
- print the warning for the debug level only because cases there can be cases 
when a binary object doesn't have a field that is set in the indexes.

In addition revisit the rest of the code removing conversion of BinaryObject to 
String at places that could lead to performance degradation.



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

Re: Ignite 1.6 release timelines

[Denis Magda]

I would add support of the binary mode for distributed data structures 
and atomic references

https://issues.apache.org/jira/browse/IGNITE-2701

Is anyone interested to pick up this task and implement?

--
Denis

On 2/18/2016 1:36 PM, Vladimir Ozerov wrote:

I would definitely want to include NuGet and ODBC into upcoming release.
Both issues are in review for now. I expect they will be in master in a
week or so.

LINQ is "nice to have" for me for this release. It changes .NET packaging
and moreover must be tested very thoroughly. So it would be cool to include
it as well, but I do not think it is a showstopper for 1.6.

On Thu, Feb 18, 2016 at 12:47 PM, Pavel Tupitsyn 
wrote:


There are some important .NET features on review, like LINQ and NuGet:
https://issues.apache.org/jira/browse/IGNITE-1630
https://issues.apache.org/jira/browse/IGNITE-1626

Vova can clarify which of them are going to be included in 1.6.

Thanks,


On Thu, Feb 18, 2016 at 12:42 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


Yakov,

Nothing major from my side is planned for 1.6. There is a ticket
IGNITE-2610 that I am currently working on (it is almost finished), but I
believe it does not make any restrictions for the schedule.




--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

[jira] [Created] (IGNITE-2714) Cleanup GridOffHeapPartitionedMap when cache is destroyed

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-2714:


 Summary: Cleanup GridOffHeapPartitionedMap when cache is destroyed
 Key: IGNITE-2714
 URL: https://issues.apache.org/jira/browse/IGNITE-2714
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Semen Boikov
Assignee: Yakov Zhdanov
Priority: Critical
 Fix For: 1.6


For cache with offheap enabled GridOffHeapPartitionedMap is created (see 
GridOffHeapProcessor).  But this GridOffHeapPartitionedMap is not removed when 
cache is destroyed.



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

[GitHub] ignite pull request: IGNITE-2584

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-2584



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

$ git pull https://github.com/ilantukh/ignite ignite-2584

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

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


commit 49f82e62d98ea5f057c0b69fbb40cff942e52599
Author: Ilya Lantukh 
Date:   2016-02-24T10:02:41Z

ignite-2584 : Changed part2node value type to list.

commit f70dcdd5b4713a880153e2f1aae22126e2f33964
Author: Ilya Lantukh 
Date:   2016-02-24T10:34:23Z

ignite-2584 : Fixed comments.




---
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.
---

CacheException in method signatures

[Yakov Zhdanov]

Guys,

Please take a look at stacktrace reported here -
http://apache-ignite-users.70518.x6.nabble.com/Exception-on-Ignite-cluster-shutdown-td3129.html

Here we have Cache.close() method throwing CacheException which is not
declared.

Val, can you please review the signatures and fix issues of the kind?

--Yakov

Re: newbie tickets

[Anton Vinogradov]

Done,

Updated to
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20labels%20in%20(newbie)%20and%20status%20%3D%20OPEN

On Wed, Feb 24, 2016 at 12:15 PM, Yakov Zhdanov  wrote:

> I think link should be
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20labels%20in%20(newbie)
>
> --Yakov
>
> 2016-02-24 12:14 GMT+03:00 Yakov Zhdanov :
>
> > I cleared component field for tickets and added label instead. Anton, can
> > you please change link on the website to search by label?
> >
> > --Yakov
> >
> > 2016-02-24 11:50 GMT+03:00 Dmitriy Setrakyan :
> >
> >> I agree, label makes more sense.
> >>
> >> On Tue, Feb 23, 2016 at 8:55 PM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> >>
> >> > Folks,
> >> >
> >> > I noticed that the 'newbie' filter on site [1] searches issues by
> >> > *component*. But it seems to me that the majority of such tickets are
> >> > marked with a label instead, so contributors don't see them when they
> >> open
> >> > this link.
> >> >
> >> > Is there a policy? For me label makes more sense. 'newbie' is not a
> >> > component.
> >> >
> >> > [1]
> >> >
> >> >
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20component%20in%20(newbie)
> >> >
> >> > -Val
> >> >
> >>
> >
> >
>

Re: newbie tickets

[Yakov Zhdanov]

I think link should be

https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20labels%20in%20(newbie)

--Yakov

2016-02-24 12:14 GMT+03:00 Yakov Zhdanov :

> I cleared component field for tickets and added label instead. Anton, can
> you please change link on the website to search by label?
>
> --Yakov
>
> 2016-02-24 11:50 GMT+03:00 Dmitriy Setrakyan :
>
>> I agree, label makes more sense.
>>
>> On Tue, Feb 23, 2016 at 8:55 PM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>> > Folks,
>> >
>> > I noticed that the 'newbie' filter on site [1] searches issues by
>> > *component*. But it seems to me that the majority of such tickets are
>> > marked with a label instead, so contributors don't see them when they
>> open
>> > this link.
>> >
>> > Is there a policy? For me label makes more sense. 'newbie' is not a
>> > component.
>> >
>> > [1]
>> >
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20component%20in%20(newbie)
>> >
>> > -Val
>> >
>>
>
>

Re: newbie tickets

[Yakov Zhdanov]

I cleared component field for tickets and added label instead. Anton, can
you please change link on the website to search by label?

--Yakov

2016-02-24 11:50 GMT+03:00 Dmitriy Setrakyan :

> I agree, label makes more sense.
>
> On Tue, Feb 23, 2016 at 8:55 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Folks,
> >
> > I noticed that the 'newbie' filter on site [1] searches issues by
> > *component*. But it seems to me that the majority of such tickets are
> > marked with a label instead, so contributors don't see them when they
> open
> > this link.
> >
> > Is there a policy? For me label makes more sense. 'newbie' is not a
> > component.
> >
> > [1]
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20component%20in%20(newbie)
> >
> > -Val
> >
>

Re: newbie tickets

[Dmitriy Setrakyan]

I agree, label makes more sense.

On Tue, Feb 23, 2016 at 8:55 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Folks,
>
> I noticed that the 'newbie' filter on site [1] searches issues by
> *component*. But it seems to me that the majority of such tickets are
> marked with a label instead, so contributors don't see them when they open
> this link.
>
> Is there a policy? For me label makes more sense. 'newbie' is not a
> component.
>
> [1]
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20component%20in%20(newbie)
>
> -Val
>

Re: Binary object inside Externalizable

[Dmitriy Setrakyan]

I am always in favor of easy fixes :)

On Tue, Feb 23, 2016 at 8:50 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Actually, adding Externalizable support to binary marshaller should not be
> difficult, no? BinaryWriterExImpl already implements ObjectOutput, so we
> just need to pass to writeExternal (and the same for deserialization). To
> be honest, I don't understand why we use optimized marshaller here and
> making this change should fix majority of use cases.
>
> The issue will remain for writeObject/readObject which is much more
> complicated and where using optimized marshaller makes more sense. But this
> is a relatively rare case and I think we can fix this as a next step.
>
> Thoughts?
>
> On Sat, Feb 20, 2016 at 10:01 AM, Dmitriy Setrakyan  >
> wrote:
>
> > Andrey, you are absolutely right. I was suggesting a quick fix, which in
> my
> > view, would fix most of the issues. In the long term, we should fix the
> > binary serialization to work the way you are describing.
> >
> > D.
> >
> > On Sat, Feb 20, 2016 at 9:26 AM, Andrey Kornev  >
> > wrote:
> >
> > > Val,
> > >
> > > I think Ignite Serialization should follow the approach similar to what
> > > Java serialization does: it can transparently and consistently handle
> > both
> > > Serializable and Externalizable classes. It can do it because it relies
> > on
> > > a single class - ObjectOutputStream - to do serialization (and a single
> > > class - ObjectInputStream - to do the opposite, but let's ignore it for
> > the
> > > moment). ObjectOutputStream delegates to proper user callbacks
> > (writeObject
> > > or writeExternal) at the right moments, but otherwise it fully controls
> > the
> > > on-the-wire representation and takes care of all the necessary stream
> > > framing/marking so that ObjectInputStream can then correctly
> deserialize
> > > the bytes. It's never a problem for Java to serialize an Externalizable
> > > field from a Serializable object and vice versa. Users can mix and
> match
> > > serialization APIs as they please.
> > >
> > > I think Ignite should just have a single marshaller, let's say the
> > Binary,
> > > which drives the whole serialization process. It doesn't delegate to
> > > OptimizedMarshaller as it does today. Instead it detects the
> > > Serializable/Externalizable classes and calls their serialization
> > callbacks
> > > - writeObject/writeExternal - passing in *itself* as
> > > ObjectOutputStream/ObjectOutput correspondingly. This way the entire
> > > serialization process never leaves the context of a single Binary
> > > marshaller and allows Ignite to handle such complex cases as the one
> > we're
> > > discussing now.
> > >
> > > I hope it makes sense.
> > >
> > > Andrey
> > >
> > > > From: valentin.kuliche...@gmail.com
> > > > Date: Fri, 19 Feb 2016 19:15:07 -0800
> > > > Subject: Binary object inside Externalizable
> > > > To: dev@ignite.apache.org
> > > >
> > > > Folks,
> > > >
> > > > I recently faced an issue which seems to be pretty critical. As you
> > know,
> > > > when binary marshaller meets an Externalizable object, it switches to
> > > > optimized marshaller. And if there is a regular object inside, it's
> > still
> > > > serialized with optimized, even if its type is declared in binary
> > > > configuration with custom mapper, etc. This looks wrong.
> > > >
> > > > It's getting even worse in compute grid, because closure processor
> > wraps
> > > > user's closures in some internal classes, which are Externalizable,
> so
> > > > these closures are always serialized with optimized marshaller.
> > > >
> > > > Does anyone have ideas on what is the proper fix for this?
> > > >
> > > > -Val
> > >
> > >
> >
>

[jira] [Created] (IGNITE-2713) 'Project structure' doesn't show the 'resources' folder inside 'src' folder

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2713:
--

 Summary: 'Project structure' doesn't show the 'resources' folder 
inside 'src' folder
 Key: IGNITE-2713
 URL: https://issues.apache.org/jira/browse/IGNITE-2713
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Priority: Trivial


It seems that we forgot about 'resources' folder which contain the 
'secret.properties' file.



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