newbie tickets

[Valentin Kulichenko]

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

[Valentin Kulichenko]

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

Re: IGNITE-1144

[Valentin Kulichenko]

Here is the list of newbie tickets:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20(component%20in%20(newbie)%20OR%20labels%20in%20(newbie))

You can pick one of them and start working.

-Val

On Tue, Feb 23, 2016 at 5:38 PM, Dood@ODDO  wrote:

> On 2/23/2016 7:05 PM, Valentin Kulichenko wrote:
>
>> I added couple more tests and merged your changes into master. Thanks for
>> the contribution!
>>
>
> Thanks! What other ticket do you think I could/should tackle?
>

[jira] [Created] (IGNITE-2711) Stop auto refresh of query on removing of paragraph

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2711:
-

 Summary: Stop auto refresh of query on removing of paragraph
 Key: IGNITE-2711
 URL: https://issues.apache.org/jira/browse/IGNITE-2711
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Reporter: Vasiliy Sisko


Query continue execution on removing of paragraph



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

[GitHub] ignite pull request: IGNITE-2416: TcpDiscoverySharedFsIpFinder to ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: IGNITE-1144

[Dood]

On 2/23/2016 7:05 PM, Valentin Kulichenko wrote:

I added couple more tests and merged your changes into master. Thanks for
the contribution!


Thanks! What other ticket do you think I could/should tackle?

[GitHub] ignite pull request: Ignite 2560

[AlexeyStelmak]

GitHub user AlexeyStelmak opened a pull request:

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

Ignite 2560



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

$ git pull https://github.com/AlexeyStelmak/ignite ignite-2560

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

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


commit afaf4809c2c2256fe4954f32e109cfef2793da6f
Author: Stelmak Alexey 
Date:   2016-02-11T17:13:25Z

ignite-2560 Support injections in entry processors

commit 3f9d011a10442e2431640df333424fa1dbefa123
Author: Stelmak Alexey 
Date:   2016-02-24T01:05:01Z

IGNITE-2560




---
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: IGNITE-1144

[Valentin Kulichenko]

I added couple more tests and merged your changes into master. Thanks for
the contribution!

-Val

On Mon, Feb 22, 2016 at 9:13 PM, Dood@ODDO  wrote:

> Val,
>
> All the test passed on TC - you can look at the PR at any time. Thanks!
>
>
> On 2/22/2016 8:13 PM, Valentin Kulichenko wrote:
>
>> Hi,
>>
>> Thanks for the pull request! I will take a look as soon as possible.
>>
>> -Val
>>
>> On Mon, Feb 22, 2016 at 9:14 AM, Dood@ODDO  wrote:
>>
>> Hello all,
>>>
>>> I was wondering if anyone can take a look at the PR I submitted for
>>> IGNITE-1144 [1]. It compiles and I think the code is good but the tests I
>>> submitted are failing - specifically, one test: I am using assertThrows()
>>> to make sure that an exception is thrown if affinityRun() is invoked on a
>>> queue that is not collocated. In the tests I basically set up a queue
>>> that
>>> has a configuration that invokes setCollocated(false) and then I invoke
>>> an
>>> affinityRun() with an "empty" job. For some reason the tests are failing
>>> with an error that the exception wasn't thrown. However, in this case I
>>> actually think that my test is bad and the PR code is good ;-). Can
>>> someone
>>> with more Java experience take a quick look?
>>>
>>> Thanks!
>>>
>>> [1] https://issues.apache.org/jira/browse/IGNITE-1144
>>>
>>>
>

[GitHub] ignite pull request: IGNITE-1144 Add affinity functions to colloca...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: streamer documentation

[李玉珏]

chinese version updated.

在 16/2/22 04:46, Raul Kripalani 写道:

Done. Cheers.

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io | twitter: @raulvk 

On Thu, Feb 11, 2016 at 6:31 AM, Denis Magda  wrote:


Thanks Raul!

Please don't forget to add the doc to both 1.5 and 1.6 [1], that has been
recently created.

[1] https://apacheignite.readme.io/v1.6

--
Denis


On 2/11/2016 1:34 AM, Raul Kripalani wrote:


Hey guys,

I'll take care of Camel and MQTT this week(end).

Thanks for the patience.

Cheers,
Raúl.

On Tue, 2 Feb 2016 08:49 Denis Magda  wrote:

Dmitriy,

Raul contributed both Camel and MQTT.
Twitter streamer was implemented by Lalit Kumar Jha.

Actually I tried reach out both Raul and Lalit Kumar Jha earlier
regarding this topic but seems that they were too busy because I didn't
get any response from them.

Raul, Lalit Kumar Jha, do you have time to add the documentation or
someone else from the community should take care of this?

Regards,
Denis

On 2/2/2016 11:42 AM, Dmitriy Setrakyan wrote:


Denis,

Is there any chance you can mention the names of the contributors, so we
could reach out to them personally and ask for help with the


documentation?


I know that Camel streamer was done by Raul, but not sure about the
other
two.

D.

On Tue, Feb 2, 2016 at 12:37 AM, Denis Magda 


wrote:


The tickets are already there

Twitter: https://issues.apache.org/jira/browse/IGNITE-2413
MQTT: https://issues.apache.org/jira/browse/IGNITE-2411
Camel: https://issues.apache.org/jira/browse/IGNITE-2530

It would be perfect if Igniters who contributed this functionality will
add the documentation as well.

--
Denis


On 2/2/2016 11:31 AM, Dmitriy Setrakyan wrote:

Igniters,

I have been trying to find documentation for the following streamers


but

couldn’t:

- Camel
- MQTT
- Twitter

Can I ask the contributors to document these features on readme?

Thanks,
D.

Re: ODBC processor default behaviour

[Sergi Vladykin]

I think both approaches are ok if the odbc client understands how should it
deal with connection failures (should it go through a port range or retry a
single port during the period of time).

Sergi

2016-02-23 4:35 GMT+03:00 Valentin Kulichenko :

> I think the behavior of OdbcProcessor should be consistent with
> RestProcessor. It tries a configurable range of ports, binds to the first
> available and prints it out in the log.
>
> -Val
>
> On Sat, Feb 20, 2016 at 7:33 AM, Yakov Zhdanov 
> wrote:
>
> > Not sure if it works. DB connection string should have certain port
> afaik.
> >
> > --Yakov
> >
> > 2016-02-20 18:26 GMT+03:00 Sergey Kozlov :
> >
> > > What's about to use the port range like TcpDiscoveryVmIpFinder?
> > >
> > > On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov 
> > > wrote:
> > >
> > > > How about outputting warning like and keep retrying in a background
> > > thread?
> > > >
> > > > warning - "Failed to bind ODBC processor TCP server to port (retrying
> > > every
> > > > 2 sec) [port=ABC]
> > > >
> > > > --Yakov
> > > >
> > > > 2016-02-20 17:38 GMT+03:00 Igor Sapego :
> > > >
> > > > > Igniters,
> > > > >
> > > > > I'm currently working on the ODBC driver. It connects by TCP to the
> > > > > OdbcProcessor
> > > > > on the node side. OdbcProcessor is enabled by default and it starts
> > TCP
> > > > > server on the
> > > > > specific TCP port or throws exception if the port is busy.
> > > > >
> > > > > The problem is that such behavior breaks tests that start more than
> > one
> > > > > node on the
> > > > > same machine as the second node fails to start because ODBC port is
> > > > already
> > > > > taken
> > > > > by the first node.
> > > > >
> > > > > Does anyone has ideas what is the best way to fix that?
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>