[jira] [Created] (IGNITE-1786) Need to implement ODBC driver for Ignite
Dmitriy Setrakyan created IGNITE-1786: - Summary: Need to implement ODBC driver for Ignite Key: IGNITE-1786 URL: https://issues.apache.org/jira/browse/IGNITE-1786 Project: Ignite Issue Type: New Feature Components: clients Reporter: Dmitriy Setrakyan Fix For: 1.6 # We have a C++ API for Ignite which starts JVM internally. Probably we can just add that ODBC API there. # Another approach is to implement really separate driver and a network server on java side which will interact with each other. The first one is simpler and probably more effective, but heavyweight. The second one is probably slower but but more lightweight. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Account @ TeamCity, please
Raul, you should be able to create an account and login by yourself. Then you will be able to trigger builds manually. D. On Fri, Oct 23, 2015 at 11:14 AM, Raul Kripalani wrote: > Hey guys, > > Could someone please create an account for me @ TeamCity with committer/PMC > permissions? > > Thanks, > > *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 > http://blog.raulkr.net | twitter: @raulvk >
Re: MQTT Streamer Code Style and Javadoc fixes (IGNITE-1747)
Dmitriy,
The first step is to write a complete specification for a coding style.
It's still incomplete from what I see.
It's inadmissible that new rules pop up in an ad hoc manner during reviews,
based on a single person's judgement.
If it's not documented in the guidelines, it *cannot be enforced*, neither
to contributors nor to committers. No one is a mind reader and no one is
going to spend the time to go through all of Ignite's codebase to infer
"unwritten rules" and apply them. That's what the guidelines are for.
@Yakov — could you please enhance the guidelines ASAP?
@Dmitriy — just to be clear again. I'm not complaining about following the
guidelines. My intentions are (1) complete coverage in the guidelines and
(2) to challenge some rules which just provide fluff with arguable value
(IMHO). Never have I questioned the necessity of a clean and uniform
codebase. This is primordial in successful OSS.
Regards,
Raúl.
On 23 Oct 2015 21:01, "Dmitriy Setrakyan" wrote:
> Gents,
>
> First of all, can I ask why this review is being done on the dev list
> instead of in the Jira? All we are doing is splitting the communication
> about the same feature into multiple places. I believe we have all agreed
> in the past that Jira is the proper place for it.
>
> Now, I have not done the review, so I cannot comment on any type of
> concurrency or bug fixing. As far as error messages starting with the word
> “Failed to …”, I can see a potential reason for it. For example, I can do a
> grep in the log for the word “Failed to” and find many error messages
> easily. To Raul’s point, it is not mentioned in the coding guidelines, so
> it should be up to the project veterans to make sure that the coding
> guidelines are properly updated (I am sure we are going to keep finding
> such omissions here and there until we get it perfect).
>
> Generally speaking, the purpose of the coding guidelines is to make the
> code more consistent. We have been getting a lot of praise for the quality
> of Ignite code, and I believe that it is mainly due to the strict coding
> guidelines rules.
>
> I will start another discussion thread on the dev list asking everyone in
> the community, contributors or committers, whether the current guidelines
> should be relaxed.
>
> D.
>
> On Fri, Oct 23, 2015 at 9:56 AM, Raul Kripalani wrote:
>
> > Hey Yakov,
> >
> > About the exception messages, come on, you have to admit you are making
> up
> > rules as we go ;-)
> >
> > Nowhere in the coding guidelines does it say that all exception messages
> > have to start with "Failed to...". In fact, there are hundreds if not
> > thousands of Exception messages in the existing Ignite codebase.
> Examples:
> >
> > throw new IgniteException("Spring application context resource is not
> > injected.");
> > throw new IgniteException("Cache store was not properly
> initialized.");
> > throw new IgniteClientDisconnectedException(reconnectFut, "Client
> node
> > disconnected: " + gridName);
> > throw new GridClientClosedException("Client was closed (no public
> > methods of client can be used anymore).");
> >
> > About the full stop at the end, there is a reference, but the way it's
> > written is incorrect (make each token start with upper case and end with
> a
> > dot?!?!)
> >
> > Note that all prefix, postfix, name, value should follow English
> > grammar, in particular, start with upper case and end with the dot '.'.
> >
> > Moreover, not even the examples on the Wiki are following that rule.
> > Neither are lots of exceptions in the current code base... Please review
> > the whole situation as it seems that double standards are being applied
> for
> > old vs. newly contributed code.
> >
> > Also, I noticed that you changed all of my inline comments to upper case
> > and finished them with a dot. Could you please add this rule to the Wiki?
> >
> > Finally, I have pushed a new version of the streamer that checks the
> > connection state by calling MqttStreamer#isConnected. Changed the retrier
> > accordingly and added 2 unit tests.
> >
> > I don't consider syncConn is an appropriate nor user-friendly
> denominator.
> >
> > Regards,
> >
> > *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
> > http://blog.raulkr.net | twitter: @raulvk
> >
> > On Fri, Oct 23, 2015 at 8:12 AM, Yakov Zhdanov
> > wrote:
> >
> > > Raul,
> > >
> > > My comments are below.
> > >
> > > 2015-10-22 22:22 GMT+03:00 Raul Kripalani :
> > >
> > > > Hi Yakov,
> > > >
> > > > Thanks for the review.
> > > >
> > > > Comments inline.
> > > >
> > > > Aside from them: being honest, do you think Javadoc like the
> following
> > > > snippets are useful and provide any value? More so in a test case...
> > > >
> > > > Snippet #1:
> > > >
> > > > /**
> > > > * @param topics Topics.
> > > > * @param fromIdx From index.
> > > >
Re: MQTT Streamer Code Style and Javadoc fixes (IGNITE-1747)
Gents,
First of all, can I ask why this review is being done on the dev list
instead of in the Jira? All we are doing is splitting the communication
about the same feature into multiple places. I believe we have all agreed
in the past that Jira is the proper place for it.
Now, I have not done the review, so I cannot comment on any type of
concurrency or bug fixing. As far as error messages starting with the word
“Failed to …”, I can see a potential reason for it. For example, I can do a
grep in the log for the word “Failed to” and find many error messages
easily. To Raul’s point, it is not mentioned in the coding guidelines, so
it should be up to the project veterans to make sure that the coding
guidelines are properly updated (I am sure we are going to keep finding
such omissions here and there until we get it perfect).
Generally speaking, the purpose of the coding guidelines is to make the
code more consistent. We have been getting a lot of praise for the quality
of Ignite code, and I believe that it is mainly due to the strict coding
guidelines rules.
I will start another discussion thread on the dev list asking everyone in
the community, contributors or committers, whether the current guidelines
should be relaxed.
D.
On Fri, Oct 23, 2015 at 9:56 AM, Raul Kripalani wrote:
> Hey Yakov,
>
> About the exception messages, come on, you have to admit you are making up
> rules as we go ;-)
>
> Nowhere in the coding guidelines does it say that all exception messages
> have to start with "Failed to...". In fact, there are hundreds if not
> thousands of Exception messages in the existing Ignite codebase. Examples:
>
> throw new IgniteException("Spring application context resource is not
> injected.");
> throw new IgniteException("Cache store was not properly initialized.");
> throw new IgniteClientDisconnectedException(reconnectFut, "Client node
> disconnected: " + gridName);
> throw new GridClientClosedException("Client was closed (no public
> methods of client can be used anymore).");
>
> About the full stop at the end, there is a reference, but the way it's
> written is incorrect (make each token start with upper case and end with a
> dot?!?!)
>
> Note that all prefix, postfix, name, value should follow English
> grammar, in particular, start with upper case and end with the dot '.'.
>
> Moreover, not even the examples on the Wiki are following that rule.
> Neither are lots of exceptions in the current code base... Please review
> the whole situation as it seems that double standards are being applied for
> old vs. newly contributed code.
>
> Also, I noticed that you changed all of my inline comments to upper case
> and finished them with a dot. Could you please add this rule to the Wiki?
>
> Finally, I have pushed a new version of the streamer that checks the
> connection state by calling MqttStreamer#isConnected. Changed the retrier
> accordingly and added 2 unit tests.
>
> I don't consider syncConn is an appropriate nor user-friendly denominator.
>
> Regards,
>
> *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
> http://blog.raulkr.net | twitter: @raulvk
>
> On Fri, Oct 23, 2015 at 8:12 AM, Yakov Zhdanov
> wrote:
>
> > Raul,
> >
> > My comments are below.
> >
> > 2015-10-22 22:22 GMT+03:00 Raul Kripalani :
> >
> > > Hi Yakov,
> > >
> > > Thanks for the review.
> > >
> > > Comments inline.
> > >
> > > Aside from them: being honest, do you think Javadoc like the following
> > > snippets are useful and provide any value? More so in a test case...
> > >
> > > Snippet #1:
> > >
> > > /**
> > > * @param topics Topics.
> > > * @param fromIdx From index.
> > > * @param cnt Count.
> > > * @param singleMsg Single message flag.
> > > * @throws MqttException If failed.
> > > */
> > >
> >
> > This makes sense for me - this makes code looks consistent.
> >
> >
> > >
> > > Snippet #2:
> > >
> > > /**
> > > * @throws Exception If failed.
> > > */
> > >
> > > To me, they are redundant. And I'm concerned about imposing superfluous
> > > Javadoc "just because", or due to aesthetics, rather than value.
> > >
> >
> > This is not so redundant. If some special condition should be mentioned -
> > go ahead and put it to javadoc. This javadoc shows at least that
> developer
> > has not just forget to put the description and there are no special
> > conditions to mention.
> >
> > Moreover, I thought I saw couple of places where javadoc stated @throws,
> > but method did not throw any exception. It seems I fixed that. Can you
> > please take a look at my changes?
> >
> > Another point - javadoc to streamer public method
> (isBlockUntilConnected())
> > was completely omitted. I hope everyone agrees that configurational
> methods
> > should be documented.
> >
> >
> > >
> > > Regards,
> > >
> > > *Raúl Kripalani*
> > > PMC &
[jira] [Created] (IGNITE-1785) .Net: Improve PlatformMemory/PortableStream performance and memory usage
Pavel Tupitsyn created IGNITE-1785: --- Summary: .Net: Improve PlatformMemory/PortableStream performance and memory usage Key: IGNITE-1785 URL: https://issues.apache.org/jira/browse/IGNITE-1785 Project: Ignite Issue Type: Improvement Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 * PlatformMemory is just a single "long _memPtr" and can be easily converted to a struct to reduce allocations (it is allocated a lot) * PlatformMemoryStream works with PlatformMemory.Length and Capacity indirectly. By employing a struct approach from https://issues.apache.org/jira/browse/IGNITE-1428 we can work with Length and Capacity directly, which may be faster, and will eliminate the need for SyncronizeInput/Output calls. * PlatformMemoryStream is allocated even more often than PlatformMemory, need to investigate whether it can also be a struct. See how List<>.GetEnumerator works, which is a struct. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Account @ TeamCity, please
Hey guys, Could someone please create an account for me @ TeamCity with committer/PMC permissions? Thanks, *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 http://blog.raulkr.net | twitter: @raulvk
Re: Ignite Web Console - Loading metadata from MySQL
Alexey, This what my table looked like. | person | CREATE TABLE `person` ( `id` int(11) NOT NULL, `orgId` int(11) DEFAULT NULL, `name` varchar(255) DEFAULT NULL, `salary` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | But I dropped the table and re-created. Works fine now. Thanks, -P On Fri, Oct 23, 2015 at 9:49 AM, Alexey Kuznetsov wrote: > Prachi, > > You get such message because some of your tables do not have PRIMARY KEY > defined. > Could you show you table definition here (SQL scrtipt)? > May be we have a bug for MySql metadata extraction logic. > > Web Console use fields from PRIMARY KEY to describe Key POJO that will be > used later as key to put values into cache. > > You could read about primary keys here: > https://en.wikipedia.org/wiki/Unique_key#Defining_primary_keys_in_SQL > > Any way, primary keys is not mandatory and after metadata loaded one can > specify key fields manually. > > > > > On Fri, Oct 23, 2015 at 11:36 PM, Prachi Garg wrote: > > > On Thu, Oct 22, 2015 at 7:04 PM, Alexey Kuznetsov < > akuznet...@gridgain.com > > > > > wrote: > > > > > Prachi, > > > > > > If this issue: https://issues.apache.org/jira/browse/IGNITE-1761 > > > > > > Is the same as you propose? > > > > > > > Yes, looks like the same thing :-) > > > > > > > > P.S. > > > Did you managed to load metadata from your MySQL database? > > > > > > > I did. But when I try to select the table and load the metadata, I get > the > > following message - > > "Some tables have no primary key. > > You will need to configure key type and key fields for such tables after > > load complete." > > Even though I have a primary key specified in my table. Am I missing > > something? > > > > Thanks, > > -P > > > > > > > > On Fri, Oct 23, 2015 at 1:06 AM, Prachi Garg wrote: > > > > > > > Thanks! > > > > > > > > I think we should also provide an option on the client side for the > > user > > > to > > > > browse to the local folder of his system. > > > > > > > > -P > > > > > > > > On Thu, Oct 22, 2015 at 12:39 AM, Dmitriy Setrakyan < > > > dsetrak...@apache.org > > > > > > > > > wrote: > > > > > > > > > On Wed, Oct 21, 2015 at 5:08 PM, Prachi Garg > > > wrote: > > > > > > > > > > > I am trying to load metadata from MySQL database, but the web > > console > > > > > > doesn't allow me to provide the MySQL driver JAR. It is set to > H2, > > by > > > > > > default, and doesn't let me change. I tried running the Ignite > web > > > > agent > > > > > in > > > > > > both test and non-test modes. How can I provide the MySQL driver > > JAR? > > > > > > > > > > > > > > > > The question (?) helper popup next to the driver field actually > > > explains > > > > > what to do. You need to copy the driver JAR into the “jdbc-drivers” > > > > folder > > > > > in the agent. > > > > > > > > > > > > > > > > Thanks, > > > > > > -Prachi > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Alexey Kuznetsov > > > GridGain Systems > > > www.gridgain.com > > > > > > > > > -- > Alexey Kuznetsov > GridGain Systems > www.gridgain.com >
Re: MQTT Streamer Code Style and Javadoc fixes (IGNITE-1747)
Hey Yakov,
About the exception messages, come on, you have to admit you are making up
rules as we go ;-)
Nowhere in the coding guidelines does it say that all exception messages
have to start with "Failed to...". In fact, there are hundreds if not
thousands of Exception messages in the existing Ignite codebase. Examples:
throw new IgniteException("Spring application context resource is not
injected.");
throw new IgniteException("Cache store was not properly initialized.");
throw new IgniteClientDisconnectedException(reconnectFut, "Client node
disconnected: " + gridName);
throw new GridClientClosedException("Client was closed (no public
methods of client can be used anymore).");
About the full stop at the end, there is a reference, but the way it's
written is incorrect (make each token start with upper case and end with a
dot?!?!)
Note that all prefix, postfix, name, value should follow English
grammar, in particular, start with upper case and end with the dot '.'.
Moreover, not even the examples on the Wiki are following that rule.
Neither are lots of exceptions in the current code base... Please review
the whole situation as it seems that double standards are being applied for
old vs. newly contributed code.
Also, I noticed that you changed all of my inline comments to upper case
and finished them with a dot. Could you please add this rule to the Wiki?
Finally, I have pushed a new version of the streamer that checks the
connection state by calling MqttStreamer#isConnected. Changed the retrier
accordingly and added 2 unit tests.
I don't consider syncConn is an appropriate nor user-friendly denominator.
Regards,
*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
http://blog.raulkr.net | twitter: @raulvk
On Fri, Oct 23, 2015 at 8:12 AM, Yakov Zhdanov
wrote:
> Raul,
>
> My comments are below.
>
> 2015-10-22 22:22 GMT+03:00 Raul Kripalani :
>
> > Hi Yakov,
> >
> > Thanks for the review.
> >
> > Comments inline.
> >
> > Aside from them: being honest, do you think Javadoc like the following
> > snippets are useful and provide any value? More so in a test case...
> >
> > Snippet #1:
> >
> > /**
> > * @param topics Topics.
> > * @param fromIdx From index.
> > * @param cnt Count.
> > * @param singleMsg Single message flag.
> > * @throws MqttException If failed.
> > */
> >
>
> This makes sense for me - this makes code looks consistent.
>
>
> >
> > Snippet #2:
> >
> > /**
> > * @throws Exception If failed.
> > */
> >
> > To me, they are redundant. And I'm concerned about imposing superfluous
> > Javadoc "just because", or due to aesthetics, rather than value.
> >
>
> This is not so redundant. If some special condition should be mentioned -
> go ahead and put it to javadoc. This javadoc shows at least that developer
> has not just forget to put the description and there are no special
> conditions to mention.
>
> Moreover, I thought I saw couple of places where javadoc stated @throws,
> but method did not throw any exception. It seems I fixed that. Can you
> please take a look at my changes?
>
> Another point - javadoc to streamer public method (isBlockUntilConnected())
> was completely omitted. I hope everyone agrees that configurational methods
> should be documented.
>
>
> >
> > Regards,
> >
> > *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
> > http://blog.raulkr.net | twitter: @raulvk
> >
> > On Thu, Oct 22, 2015 at 11:52 AM, Yakov Zhdanov
> > wrote:
> >
> > > Hi Raul!
> > >
> > > Thank you very much for addressing my comments!
> > >
> > > I like the code however there are still a couple of points (I committed
> > > everything to ignite-1747):
> > >
> > > 1. Please take a look at
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-StringOutput
> >
> >
> > Yeah, I'm familiar with this rule and I thought I was complying with it.
> > Could you give me an example where the code is not compliant?
> >
>
> throw new IgniteException("Exception while initializing
> MqttStreamer", t); - does not start with "Failed to.." and does not end
> with dot
> throw new IgniteException("Attempted to stop an already stopped
> MQTT Streamer");
> throw new IgniteException("Exception while stopping
> MqttStreamer", t);
>
> + 'MqttStreamer' vs 'MQTT Streamer' inconsistency. I like 'MQTT Streamer'
> more.
>
> I thought I changed those lines. Can you please take a look at my changes?
>
>
> >
> >
> > > 2. org.apache.ignite.stream.mqtt.MqttStreamer#connected - volatile
> write
> > > then read of most likely the same value - I changed it to return true
> > > literal.
> > > connected = true;
> > > retu
Re: Ignite Web Console - Loading metadata from MySQL
Prachi, You get such message because some of your tables do not have PRIMARY KEY defined. Could you show you table definition here (SQL scrtipt)? May be we have a bug for MySql metadata extraction logic. Web Console use fields from PRIMARY KEY to describe Key POJO that will be used later as key to put values into cache. You could read about primary keys here: https://en.wikipedia.org/wiki/Unique_key#Defining_primary_keys_in_SQL Any way, primary keys is not mandatory and after metadata loaded one can specify key fields manually. On Fri, Oct 23, 2015 at 11:36 PM, Prachi Garg wrote: > On Thu, Oct 22, 2015 at 7:04 PM, Alexey Kuznetsov > > wrote: > > > Prachi, > > > > If this issue: https://issues.apache.org/jira/browse/IGNITE-1761 > > > > Is the same as you propose? > > > > Yes, looks like the same thing :-) > > > > > P.S. > > Did you managed to load metadata from your MySQL database? > > > > I did. But when I try to select the table and load the metadata, I get the > following message - > "Some tables have no primary key. > You will need to configure key type and key fields for such tables after > load complete." > Even though I have a primary key specified in my table. Am I missing > something? > > Thanks, > -P > > > > On Fri, Oct 23, 2015 at 1:06 AM, Prachi Garg wrote: > > > > > Thanks! > > > > > > I think we should also provide an option on the client side for the > user > > to > > > browse to the local folder of his system. > > > > > > -P > > > > > > On Thu, Oct 22, 2015 at 12:39 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > wrote: > > > > > > > On Wed, Oct 21, 2015 at 5:08 PM, Prachi Garg > > wrote: > > > > > > > > > I am trying to load metadata from MySQL database, but the web > console > > > > > doesn't allow me to provide the MySQL driver JAR. It is set to H2, > by > > > > > default, and doesn't let me change. I tried running the Ignite web > > > agent > > > > in > > > > > both test and non-test modes. How can I provide the MySQL driver > JAR? > > > > > > > > > > > > > The question (?) helper popup next to the driver field actually > > explains > > > > what to do. You need to copy the driver JAR into the “jdbc-drivers” > > > folder > > > > in the agent. > > > > > > > > > > > > > Thanks, > > > > > -Prachi > > > > > > > > > > > > > > > > > > > > -- > > Alexey Kuznetsov > > GridGain Systems > > www.gridgain.com > > > -- Alexey Kuznetsov GridGain Systems www.gridgain.com
Re: Ignite Web Console - Loading metadata from MySQL
On Thu, Oct 22, 2015 at 7:04 PM, Alexey Kuznetsov wrote: > Prachi, > > If this issue: https://issues.apache.org/jira/browse/IGNITE-1761 > > Is the same as you propose? > Yes, looks like the same thing :-) > > P.S. > Did you managed to load metadata from your MySQL database? > I did. But when I try to select the table and load the metadata, I get the following message - "Some tables have no primary key. You will need to configure key type and key fields for such tables after load complete." Even though I have a primary key specified in my table. Am I missing something? Thanks, -P On Fri, Oct 23, 2015 at 1:06 AM, Prachi Garg wrote: > > > Thanks! > > > > I think we should also provide an option on the client side for the user > to > > browse to the local folder of his system. > > > > -P > > > > On Thu, Oct 22, 2015 at 12:39 AM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > wrote: > > > > > On Wed, Oct 21, 2015 at 5:08 PM, Prachi Garg > wrote: > > > > > > > I am trying to load metadata from MySQL database, but the web console > > > > doesn't allow me to provide the MySQL driver JAR. It is set to H2, by > > > > default, and doesn't let me change. I tried running the Ignite web > > agent > > > in > > > > both test and non-test modes. How can I provide the MySQL driver JAR? > > > > > > > > > > The question (?) helper popup next to the driver field actually > explains > > > what to do. You need to copy the driver JAR into the “jdbc-drivers” > > folder > > > in the agent. > > > > > > > > > > Thanks, > > > > -Prachi > > > > > > > > > > > > > -- > Alexey Kuznetsov > GridGain Systems > www.gridgain.com >
[jira] [Created] (IGNITE-1784) [Failed Test] GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC sometimes.
Artem Shutak created IGNITE-1784: Summary: [Failed Test] GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC sometimes. Key: IGNITE-1784 URL: https://issues.apache.org/jira/browse/IGNITE-1784 Project: Ignite Issue Type: Test Reporter: Artem Shutak Priority: Blocker Fix For: 1.5 GridEventConsumeSelfTest.testMultithreadedWithNodeRestart fails on TC sometimes. Looks like after fail in the test all other tests hanged. See logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1783) Remove GridBoundedConcurrentLinkedHashMap and replace its usages with ConcurrentLinkedHashMap
Yakov Zhdanov created IGNITE-1783:
-
Summary: Remove GridBoundedConcurrentLinkedHashMap and replace its
usages with ConcurrentLinkedHashMap
Key: IGNITE-1783
URL: https://issues.apache.org/jira/browse/IGNITE-1783
Project: Ignite
Issue Type: Task
Reporter: Yakov Zhdanov
Priority: Trivial
>From what I see {{GridBoundedConcurrentLinkedHashMap}} is redundant and the
>only difference from {{ConcurrentLinkedHashMap}} is in order of constructor
>arguments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1782) IgniteKernal get wrong message in the log about set marshaller
Vasilisa Sidorova created IGNITE-1782:
--
Summary: IgniteKernal get wrong message in the log about set
marshaller
Key: IGNITE-1782
URL: https://issues.apache.org/jira/browse/IGNITE-1782
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.5
Environment: Ubuntu 14.04, Apache Ignite 1.5.0 build #42, rev.
0bc1d6f42e637e5bfc45aa99fdcb68fc7896ef4e
Reporter: Vasilisa Sidorova
Fix For: 1.5
-
DESCRIPTION
-
This issue have funny essence: when marshaller set into optimized IgniteKernal
doesn't get any message about marshaller into log. But when marshaller set into
another type IgniteKernal get message "set 'marshaller' to OptimizedMarshaller"
-
STEPS FOR REPRODUCE
-
# Build examples project
# Run, for example, ExampleNodeStartup with VM option "-DIGNITE_QUIET=false"
# Actual result: there isn't any message about type of marshaller (Is it
expected result?)
# Stop node
# In the example-ignite.xml change property from:
{noformat}
-->
[GitHub] ignite pull request: ignite-1718 Fix of 'Not enough data to read t...
Github user agura closed the pull request at: https://github.com/apache/ignite/pull/165 --- 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-1718 Fix of 'Not enough data to read t...
GitHub user agura reopened a pull request: https://github.com/apache/ignite/pull/165 ignite-1718 Fix of 'Not enough data to read the value' and 'No class definition for typeId: 0' in portable marshaller You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-1718 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/165.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 #165 commit a1367ef226057989695c8e635eb9d5c51ccb1514 Author: agura Date: 2015-10-19T13:31:27Z ignite-1718 Fix of 'Not enough data to read the value' and 'No class definition for typeId: 0' in portable marshaller commit 542ee46c0d53f7be0300ce983ec4726b6f4aa85f Author: agura Date: 2015-10-20T14:50:45Z ignite-1718 Fix of 'Not enough data to read the value' and 'No class definition for typeId: 0' in portable marshaller --- 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-1718 Fix of 'Not enough data to read t...
Github user agura closed the pull request at: https://github.com/apache/ignite/pull/165 --- 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-1644 .Net: DateTime.Kind is lost durin...
GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/173 IGNITE-1644 .Net: DateTime.Kind is lost during serialization You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1644 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/173.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 #173 commit a2ba025271ecbaa656aaa7d6028db49b62f494c7 Author: Pavel Tupitsyn Date: 2015-10-23T09:54:44Z wip commit bbd3fe83dd039348304132d47f77c34c4ccc0833 Author: Pavel Tupitsyn Date: 2015-10-23T09:59:38Z wip commit 1045c7db652166864b47aa525ee77a81a521e488 Author: Pavel Tupitsyn Date: 2015-10-23T10:00:07Z wip commit 364a71dc1a5d48c19c10cd9ece76c278b364552a Author: Pavel Tupitsyn Date: 2015-10-23T10:07:36Z Move serializable to handlers commit 53a6635c33a7cf24c858aa602763f8af59170b29 Author: Pavel Tupitsyn Date: 2015-10-23T10:23:12Z wip tests commit 0580580fa05b9e806dae925629d72a6c4b8be7fe Author: Pavel Tupitsyn Date: 2015-10-23T10:24:37Z wip commit dc348d1629fe152dafcb3f40bb7aec68960ca5e3 Author: Pavel Tupitsyn Date: 2015-10-23T10:33:26Z DateTimeHolder commit 05a5319a9509a405f4a47a31e94fa45bb7a3bc8f Author: Pavel Tupitsyn Date: 2015-10-23T10:36:27Z TypeDateTimeHolder commit 1dea88a903fd76f71d4ba22a7c00bd76219dc566 Author: Pavel Tupitsyn Date: 2015-10-23T10:42:28Z wip commit 3af414cd255ab1f2d0c70dbb4c0a74240d08c09b Author: Pavel Tupitsyn Date: 2015-10-23T10:48:06Z Fix DateTime arrays --- 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 Web Console - Loading metadata from MySQL
On Fri, Oct 23, 2015 at 3:16 AM, Alexey Kuznetsov wrote: > Actually it is quite hard to do. > > The main complexity that we need to implement double transfer: > 1) Transfer selected jar from user local folder to Web Console Server. > 2) Transfer jar from Web Console Server to Host were Web Agent running. > > And I would prefer to do it after first release. > Agree. I don’t think we should rush this feature. > > On Fri, Oct 23, 2015 at 5:09 PM, Dmitriy Setrakyan > wrote: > > > On Thu, Oct 22, 2015 at 7:04 PM, Alexey Kuznetsov < > akuznet...@gridgain.com > > > > > wrote: > > > > > Prachi, > > > > > > If this issue: https://issues.apache.org/jira/browse/IGNITE-1761 > > > > > > I have looked at the ticket and it seems like a very good idea and big > > usability improvement. > > > > Given that all the communication of the web-console happens through the > > agent anyway, we can load the driver JAR into the agent after the agent > had > > started. > > > > Would it be hard to do? > > > > > > > > > > Is the same as you propose? > > > > > > P.S. > > > Did you managed to load metadata from your MySQL database? > > > > > > On Fri, Oct 23, 2015 at 1:06 AM, Prachi Garg > wrote: > > > > > > > Thanks! > > > > > > > > I think we should also provide an option on the client side for the > > user > > > to > > > > browse to the local folder of his system. > > > > > > > > -P > > > > > > > > On Thu, Oct 22, 2015 at 12:39 AM, Dmitriy Setrakyan < > > > dsetrak...@apache.org > > > > > > > > > wrote: > > > > > > > > > On Wed, Oct 21, 2015 at 5:08 PM, Prachi Garg > > > wrote: > > > > > > > > > > > I am trying to load metadata from MySQL database, but the web > > console > > > > > > doesn't allow me to provide the MySQL driver JAR. It is set to > H2, > > by > > > > > > default, and doesn't let me change. I tried running the Ignite > web > > > > agent > > > > > in > > > > > > both test and non-test modes. How can I provide the MySQL driver > > JAR? > > > > > > > > > > > > > > > > The question (?) helper popup next to the driver field actually > > > explains > > > > > what to do. You need to copy the driver JAR into the “jdbc-drivers” > > > > folder > > > > > in the agent. > > > > > > > > > > > > > > > > Thanks, > > > > > > -Prachi > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Alexey Kuznetsov > > > GridGain Systems > > > www.gridgain.com > > > > > > > > > -- > Alexey Kuznetsov > GridGain Systems > www.gridgain.com >
Re: Ignite Web Console - Loading metadata from MySQL
Actually it is quite hard to do. The main complexity that we need to implement double transfer: 1) Transfer selected jar from user local folder to Web Console Server. 2) Transfer jar from Web Console Server to Host were Web Agent running. And I would prefer to do it after first release. On Fri, Oct 23, 2015 at 5:09 PM, Dmitriy Setrakyan wrote: > On Thu, Oct 22, 2015 at 7:04 PM, Alexey Kuznetsov > > wrote: > > > Prachi, > > > > If this issue: https://issues.apache.org/jira/browse/IGNITE-1761 > > > I have looked at the ticket and it seems like a very good idea and big > usability improvement. > > Given that all the communication of the web-console happens through the > agent anyway, we can load the driver JAR into the agent after the agent had > started. > > Would it be hard to do? > > > > > > Is the same as you propose? > > > > P.S. > > Did you managed to load metadata from your MySQL database? > > > > On Fri, Oct 23, 2015 at 1:06 AM, Prachi Garg wrote: > > > > > Thanks! > > > > > > I think we should also provide an option on the client side for the > user > > to > > > browse to the local folder of his system. > > > > > > -P > > > > > > On Thu, Oct 22, 2015 at 12:39 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > wrote: > > > > > > > On Wed, Oct 21, 2015 at 5:08 PM, Prachi Garg > > wrote: > > > > > > > > > I am trying to load metadata from MySQL database, but the web > console > > > > > doesn't allow me to provide the MySQL driver JAR. It is set to H2, > by > > > > > default, and doesn't let me change. I tried running the Ignite web > > > agent > > > > in > > > > > both test and non-test modes. How can I provide the MySQL driver > JAR? > > > > > > > > > > > > > The question (?) helper popup next to the driver field actually > > explains > > > > what to do. You need to copy the driver JAR into the “jdbc-drivers” > > > folder > > > > in the agent. > > > > > > > > > > > > > Thanks, > > > > > -Prachi > > > > > > > > > > > > > > > > > > > > -- > > Alexey Kuznetsov > > GridGain Systems > > www.gridgain.com > > > -- Alexey Kuznetsov GridGain Systems www.gridgain.com
Re: Ignite Web Console - Loading metadata from MySQL
On Thu, Oct 22, 2015 at 7:04 PM, Alexey Kuznetsov wrote: > Prachi, > > If this issue: https://issues.apache.org/jira/browse/IGNITE-1761 I have looked at the ticket and it seems like a very good idea and big usability improvement. Given that all the communication of the web-console happens through the agent anyway, we can load the driver JAR into the agent after the agent had started. Would it be hard to do? > > Is the same as you propose? > > P.S. > Did you managed to load metadata from your MySQL database? > > On Fri, Oct 23, 2015 at 1:06 AM, Prachi Garg wrote: > > > Thanks! > > > > I think we should also provide an option on the client side for the user > to > > browse to the local folder of his system. > > > > -P > > > > On Thu, Oct 22, 2015 at 12:39 AM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > wrote: > > > > > On Wed, Oct 21, 2015 at 5:08 PM, Prachi Garg > wrote: > > > > > > > I am trying to load metadata from MySQL database, but the web console > > > > doesn't allow me to provide the MySQL driver JAR. It is set to H2, by > > > > default, and doesn't let me change. I tried running the Ignite web > > agent > > > in > > > > both test and non-test modes. How can I provide the MySQL driver JAR? > > > > > > > > > > The question (?) helper popup next to the driver field actually > explains > > > what to do. You need to copy the driver JAR into the “jdbc-drivers” > > folder > > > in the agent. > > > > > > > > > > Thanks, > > > > -Prachi > > > > > > > > > > > > > -- > Alexey Kuznetsov > GridGain Systems > www.gridgain.com >
[jira] [Created] (IGNITE-1781) Broken query header in case of long query name
Pavel Konstantinov created IGNITE-1781: -- Summary: Broken query header in case of long query name Key: IGNITE-1781 URL: https://issues.apache.org/jira/browse/IGNITE-1781 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov Please see attachment -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1780) .Net: DateTime is seialized incorrectly.
Vladimir Ozerov created IGNITE-1780:
---
Summary: .Net: DateTime is seialized incorrectly.
Key: IGNITE-1780
URL: https://issues.apache.org/jira/browse/IGNITE-1780
Project: Ignite
Issue Type: Task
Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 1.5
Add the following test to PortableSelfTest.cs:
{code}
[Test]
public void TestWriteDate()
{
DateTime time = DateTime.Now;
DateTime timeUtc = DateTime.UtcNow;
Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
timeUtc);
}
{code}
Observe that it fails becuase we loose DateTimeKind.
DateTime must be serialized in portable form only in two cases:
1) IPortableWriter.WriteDate()
2) IPortableWriter.WriteDateArray()
In all other cases it should be serialized in some other form. E.g., we can
introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
Arrays (IGNITE-1779) in it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1779) .Net: Evaluate BinaryFormatter overhead for generic collections.
Vladimir Ozerov created IGNITE-1779: --- Summary: .Net: Evaluate BinaryFormatter overhead for generic collections. Key: IGNITE-1779 URL: https://issues.apache.org/jira/browse/IGNITE-1779 Project: Ignite Issue Type: Task Components: interop Affects Versions: ignite-1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.5 It seems that BinaryFormatter is extrmly inefficient. I tried to write a single Guid with and it resulted in >100 bytes comparing to 16 bytes when written in portable form. If we notice the same overhead for collections/arrays which are fairly often used types, we will have to revert to our initial approach when collections were serialized using our own mechanics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: MQTT Streamer Code Style and Javadoc fixes (IGNITE-1747)
Raul,
My comments are below.
2015-10-22 22:22 GMT+03:00 Raul Kripalani :
> Hi Yakov,
>
> Thanks for the review.
>
> Comments inline.
>
> Aside from them: being honest, do you think Javadoc like the following
> snippets are useful and provide any value? More so in a test case...
>
> Snippet #1:
>
> /**
> * @param topics Topics.
> * @param fromIdx From index.
> * @param cnt Count.
> * @param singleMsg Single message flag.
> * @throws MqttException If failed.
> */
>
This makes sense for me - this makes code looks consistent.
>
> Snippet #2:
>
> /**
> * @throws Exception If failed.
> */
>
> To me, they are redundant. And I'm concerned about imposing superfluous
> Javadoc "just because", or due to aesthetics, rather than value.
>
This is not so redundant. If some special condition should be mentioned -
go ahead and put it to javadoc. This javadoc shows at least that developer
has not just forget to put the description and there are no special
conditions to mention.
Moreover, I thought I saw couple of places where javadoc stated @throws,
but method did not throw any exception. It seems I fixed that. Can you
please take a look at my changes?
Another point - javadoc to streamer public method (isBlockUntilConnected())
was completely omitted. I hope everyone agrees that configurational methods
should be documented.
>
> Regards,
>
> *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
> http://blog.raulkr.net | twitter: @raulvk
>
> On Thu, Oct 22, 2015 at 11:52 AM, Yakov Zhdanov
> wrote:
>
> > Hi Raul!
> >
> > Thank you very much for addressing my comments!
> >
> > I like the code however there are still a couple of points (I committed
> > everything to ignite-1747):
> >
> > 1. Please take a look at
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-StringOutput
>
>
> Yeah, I'm familiar with this rule and I thought I was complying with it.
> Could you give me an example where the code is not compliant?
>
throw new IgniteException("Exception while initializing
MqttStreamer", t); - does not start with "Failed to.." and does not end
with dot
throw new IgniteException("Attempted to stop an already stopped
MQTT Streamer");
throw new IgniteException("Exception while stopping
MqttStreamer", t);
+ 'MqttStreamer' vs 'MQTT Streamer' inconsistency. I like 'MQTT Streamer'
more.
I thought I changed those lines. Can you please take a look at my changes?
>
>
> > 2. org.apache.ignite.stream.mqtt.MqttStreamer#connected - volatile write
> > then read of most likely the same value - I changed it to return true
> > literal.
> > connected = true;
> > return connected;
> >
>
> Agree.
>
>
> > 3. blockUntilConnected - I would name this property syncConn
> >
>
> Why? To me "blockUntilConnected" is clearer and more explicit than
> "syncConn", which sounds mystic to an ordinary user who's not familiar with
> the community's abbreviation table. It's ok for a private member, but not
> for a property. In fact, syncConn requires the user to have the Javadoc
> handy, blockUntilConnected doesn't. So I prefer the latter.
>
This name does not state that connection is blocked on start. Moreover,
this adds no value as connection may disappear right after start and
streamer should recover connection in background. Maybe we can remove it?
>
> > 4. Abbreviation rules violations - connected - conn, executor - exec,
> > values - vals, count - cnt, message - msg
> >
>
> Ok, this is a rule... yeah. But you can imagine it's extremely hard to
> memorise someone else's glossary. In my opinion, abbreviations should be
> used only when needed, not by default. An abbreviation subtracts
> readability for the general user – long-term Ignite developers are probably
> used to these by now.
>
>
> > 5. What is the point of "connected" member? Client has "isConnected()"?
> Is
> > it similar to what you want to achieve?
> >
>
> I'll look at the implementation of MqttClient.isConnected(), but off the
> top of my head, it seems it could be replaced, yes.
>
>
> > 6. Race on stop - 1 thread calls stop and successfully exits the method,
> > retrier is not stopped (awaitTermination has not been called - should it
> > be?) and can connect client back - is this the case?
> >
>
> I'll have a look.
>
>
> > 7. I think we use {@code } instead of ...
> >
>
> Correct. Thanks.
>
> On more point community should agree on - imports ordering and grouping. I
> > will post another email.
> >
>
> This was already added a few weeks ago in the Coding rules.
That's fine then.
Yakov
Re: TC patch validation
Cos, see email. -- Artem -- On Thu, Oct 22, 2015 at 9:15 PM, Konstantin Boudnik wrote: > On Thu, Oct 22, 2015 at 01:28PM, Artem Shutak wrote: > > Yes, automatic runs were disabled for patches too. > > > > To run patches you can use "Run All for patch" with specified jira number > > at "Paramethers / Jira number*". > > Right, that presumes that a user has an account. I am sure I have one, but > I > lost the password, because of the changes of the laptop and whatnot. > There's > no obvious name to reset it though; Artem could you help me to reset it and > drop me a password separately or via skype? > > Thank you very much in advance! > Cos > > > > > -- Artem -- > > > > On Thu, Oct 22, 2015 at 4:11 AM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > > > > I think Cos’ question also was why the patches attached to Jira do not > get > > > automatically run on TC. To my knowledge, the automatic runs were > disabled, > > > but I am not sure if it includes patches as well. > > > > > > Can someone clarify how to run patches on TC? > > > > > > D. > > > > > > On Fri, Oct 16, 2015 at 2:16 AM, Ivan Veselovskiy < > > > iveselovs...@gridgain.com > > > > wrote: > > > > > > > Hi, Konstantin, > > > > Tests are grouped in suites by subsystems. You can run particular > test > > > > suite -- e.g. "Ignite Hadoop". > > > > To run the tests with particular changes push the "Run..." button > near > > > that > > > > test suite and chose "pull//head" in "Build > > > > branch" field on the "Changes" tab. > > > > > > > > On Fri, Oct 16, 2015 at 1:01 AM, Konstantin Boudnik > > > > wrote: > > > > > > > > > Gents, > > > > > > > > > > is TC still picking up the JIRAs in PA state? Somehow it seems that > > > only > > > > > the > > > > > latest changes from master are being picked. > > > > > > > > > > On a somewhat similar note: can I run tests for just a single > module? > > > > E.g. > > > > > in > > > > > IGNITE-1701 I made some changes in ignite-spark pom.xml and want to > > > > quickly > > > > > verify that this doesn't affect anything (which it shouldn't, > clearly). > > > > > Running the whole testset on my tiny laptop will probably take a > few > > > > hours. > > > > > > > > > > Appreciate any pointers, thanks in advance! > > > > > Cos > > > > > > > > > > > > > > > > > >
