Re: Ignite-1.5 Release

On Wed, Nov 4, 2015 at 10:25 AM, Vladimir Ozerov wrote: > > Also I measured query performance on some local benchmarks and got > acceptable resutls - queries are about 5-7% slower with poratbles than with > OptimizedMarshaller. Looks very promising to me provided that we

Re: Distributed queue problem with peerClassLoading enabled

On Wed, Nov 4, 2015 at 4:39 AM, Alexey Goncharuk wrote: > I am not sure what behavior we want to achieve here. Do we want to > disable cache peer class loading for binary marshaling altogether? > This restriction is safe to remove only if user chooses to work

Re: [GitHub] ignite pull request: IGNITE-1854

Hi wmz7year, Can you please properly subscribe to the dev list? This way I will not have to manually approve the emails you send out to the dev list. All you need to do is send an empty email to “ dev-subscr...@ignite.apache.org” and then simply reply to the reply you receive. D. On Wed, Nov

Re: IgniteMultiMap design

Assigned IGNITE-642 and IGNITE-637 to me, and unassigned IGNITE-640. If nobody picks it up in the near future, I will do it (after I'm done with IGNITE-642 and IGNITE-637). Best regards, VJ On Thu, Nov 5, 2015 at 1:48 AM, Dmitriy Setrakyan wrote: > On Tue, Nov 3, 2015

Re: IgniteMultiMap design

On Wed, Nov 4, 2015 at 5:09 PM, Vladisav Jelisavcic wrote: > Assigned IGNITE-642 and IGNITE-637 to me, > and unassigned IGNITE-640. > > If nobody picks it up in the near future, > I will do it (after I'm done with IGNITE-642 and IGNITE-637). > > Best regards, > VJ > Thanks!

Re: [GitHub] ignite pull request: IGNITE-1854

In the distributed case, the different types of servers need to transfer objects that implement a unified interface, but each type of server implementation mechanisms are not the same, to achieve the object's class will realize Externalizable interface. Like this: interface A extends

Re: [GitHub] ignite pull request: IGNITE-1854

Hi Dmitriy Setrakyan, I have subscribe to the dev list. > 在 2015年11月5日，上午9:29，Dmitriy Setrakyan 写道： > > Hi wmz7year, > > Can you please properly subscribe to the dev list? This way I will not have > to manually approve the emails you send out to the dev list. > > All

integration with spring boot

Igniters, I am aware that Ignite supports Spring @Cacheable annotation. Does it mean that Ignite integrated with Spring boot? http://docs.spring.io/spring-boot/docs/1.3.0.M1/reference/html/boot-features-caching.html If not, we should definitely add such integration. D.

Re: Prepared statement concept in indexing

Ok, I've created jira issue and will try to put this into 1.5. release. https://issues.apache.org/jira/browse/IGNITE-1856 Sergi 2015-11-04 21:17 GMT+03:00 Vladimir Ozerov : > Agree, it would be cool if we cache parsed queries without any changes to > public API. > > But

Re: HTTP-REST sql query ID problem

On Wed, Nov 4, 2015 at 10:50 PM, Sergi Vladykin wrote: > Guys, > > It looks like that if we need state on server side it is not REST anymore. > We really need user sessions. > Everything else you will invent here is just a hack. > Sergi, we already support nodeLocal

[jira] [Created] (IGNITE-1857) We should generate download.zip directly in browser

Alexey Kuznetsov created IGNITE-1857: Summary: We should generate download.zip directly in browser Key: IGNITE-1857 URL: https://issues.apache.org/jira/browse/IGNITE-1857 Project: Ignite

Re: Ignite-1.5 Release

Folks, It looks like Ignite-950 branch is ready to be merged to ignite-1282. Can someone pull latest changes from 1.5 to ignite-1282 branch? I know some of the critical issues have been fixed lately, so I would like to give CI another run before my merge. 2015-11-04 1:50 GMT+03:00 Alexey

Re: Java 7 client using Java 7 server, or vice versa

On Wed, Nov 4, 2015 at 2:42 AM, Denis Magda wrote: > Hi, > > This limitation has already been removed for the nearest release. > Should be part of the upcoming 1.5 release. -- >> View this message in context: >>

Re: java.lang.NullPointerException or java.lang.IllegalMonitorStateException

seems to be too trivial to file ticket for. fixed in master. --Yakov 2015-11-04 11:49 GMT+03:00 Dmitriy Setrakyan : > On Wed, Nov 4, 2015 at 12:14 AM, Yakov Zhdanov > wrote: > > > Guys, > > > > We are still facing issues with quiet logging mode. Can

Re: Integration with Spring Transaction Manager

Amir, please go ahead! I have granted the necessary permissions to you. --Yakov 2015-11-04 16:48 GMT+03:00 Amir Akhmedov : > Hi Denis, > > No, my account has not been granted permissions. If you have a permission > could you grant me them. My jira account: aakhmedov > >

Re: Prepared statement concept in indexing

Sergi, I really want those 20% of performance :) Can we just cache the parsed query based on the query string that is passed in? If not, can you think of another way to do it, without changing the API? If not, can we change the API and still keep its backward-compatibility, like we do with

Re: Review the new Camel Streamer (IGNITE-1790)

Raul, sorry for the delay. I've reviewed your implementation and left minor comments in the ticket. -- Thanks, Denis On 10/29/2015 12:17 PM, Raul Kripalani wrote: Sure, that's fine. Thanks, Denis. Regards, Raúl. On 29 Oct 2015 08:50, "Denis Magda" wrote: Hi Raul,

Re: Prepared statement concept in indexing

Yes, it is a problem and I believe after distributed joins feature will be merged, it will become even worse. Though I'd prefer to avoid changing public API for now. I believe it must be enough to cache and reuse parsed query information, generated queries and other stuff. Sergi 2015-11-04

[GitHub] ignite pull request: jcsh 0.1.53

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/201 jcsh 0.1.53 You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite jcsh_0.1.53 Alternatively you can review and apply these

Prepared statement concept in indexing

Igniters, Currently I'm profiling query execution on a single node on a realtively small data set (100K entries). What I see is that query parsing consumes about 20% of all execution time. Do we have something like JDBC PreparedStatement for our queries to minimize this overhead? If no, does it

Re: Integration with Spring Transaction Manager

Hi Denis, No, my account has not been granted permissions. If you have a permission could you grant me them. My jira account: aakhmedov Thanks. 2015-11-04 15:32 GMT+03:00 Denis Magda : > Hello Amir, > > You can do it on your own. Do you have a JIRA account that was granted

Re: Integration with Spring Transaction Manager

Hello Amir, You can do it on your own. Do you have a JIRA account that was granted all required permissions? -- Denis On 11/4/2015 1:01 PM, Amir Akhmedov wrote: Hi Dmitriy, I want to give a try on this ticket. Could you assign it to me? Thanks.

Re: [GitHub] ignite pull request: IGNITE-1854

Hi wmz7year (sorry, don't know your real name), Thanks for showing the interest in Ignite and contributing to it but I'm afraid that we can't accept this particular contribution. The reason is that the checksum verification is essential for objects serialized with OptimizedMarshaller. It

Re: Distributed queue problem with peerClassLoading enabled

I am not sure what behavior we want to achieve here. Do we want to disable cache peer class loading for binary marshalling altogether? This restriction is safe to remove only if user chooses to work exclusively with Binary object representation. If user still wants to work with class object

Accepted patches/pull-requests from Roman, Ken & Stephen

Roman, Ken & Stephen, The following contributions done by you was reviewed, merged and will be a part of the nearest release. ignite-1153:Improve stop node message ignite-1226:Need to add method that returns names of all available caches

RE: OSGi migration may require a special marshaller

Raul, While we're waiting for the specific proposal(s) from you, I'd like to point out that OSGi bundle is much more than just a jar or a packaging unit. First and foremost an OSGi bundle is also a class loader unlike the jars in non-OSGi environment. We're after the class loader hence the

Re: OSGi migration may require a special marshaller

Hi Dmitriy, I found this post that explain how to find a bundle based on its bundle name and version. This post explain for the past to now how to do it in the standard way with "pull" approach: https://www.eclipse.org/forums/index.php/t/205719/ Regarding the version of OSGi you want to support

[GitHub] ignite pull request: jcsh 0.1.53

Github user agura closed the pull request at: https://github.com/apache/ignite/pull/201 --- 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

Re: OSGi migration may require a special marshaller

On Wed, Nov 4, 2015 at 9:07 AM, Romain Gilles wrote: > Hi Dmitriy, > I found this post that explain how to find a bundle based on its bundle > name and version. > This post explain for the past to now how to do it in the standard way with > "pull" approach:

Re: java.lang.NullPointerException or java.lang.IllegalMonitorStateException

On Wed, Nov 4, 2015 at 12:14 AM, Yakov Zhdanov wrote: > Guys, > > We are still facing issues with quiet logging mode. Can anyone > add information on java runtime and OS to quiet mode? > Yakov, I completely agree. I think this would be a good newbie ticket. Can you please

[GitHub] ignite pull request: IGNITE-1831 added gulp as task runner for pro...

GitHub user Dmitriyff opened a pull request: https://github.com/apache/ignite/pull/199 IGNITE-1831 added gulp as task runner for project You can merge this pull request into a Git repository by running: $ git pull https://github.com/Dmitriyff/ignite ignite-1831 Alternatively

Re: HTTP-REST sql query ID problem

How about a sequence number pattern like in the FIX protocol? So the restarted node carries on from where it left off. To make that work you would also need a client id (equivalent to a CompId in FIX) to make each request unique. On 4 Nov 2015 09:13, "Alexey Kuznetsov"

Re: HTTP-REST sql query ID problem

M G, Could you please, give a link to FIX protocol description? I would like to read about it to be on same page with you. Thanks! On Wed, Nov 4, 2015 at 4:17 PM, M G wrote: > How about a sequence number pattern like in the FIX protocol? So the > restarted node carries on

Re: HTTP-REST sql query ID problem

Alexey, No problem, here is a link that is relatively simple to understand : http://javarevisited.blogspot.co.uk/2011/02/fix-protocol-session-or-admin-messages.html However, a simplified approach of just adding a client ID seems sufficient - the sequence number reset functionality of FIX is

Fwd: Distributed queue problem with peerClassLoading enabled

Igniters, I want to bring your attention to my email response on the user list. I just want to confirm that we are all on the same page and that my understanding is correct. I think that once we merge the BinaryObject to the release branch, we should remove the restriction on SHARED or

[jira] [Created] (IGNITE-1854) OptimizedClassDescriptor verifyChecksum object set as optional

wmz7year created IGNITE-1854: Summary: OptimizedClassDescriptor verifyChecksum object set as optional Key: IGNITE-1854 URL: https://issues.apache.org/jira/browse/IGNITE-1854 Project: Ignite

Re: HTTP-REST sql query ID problem

On Wed, Nov 4, 2015 at 1:27 AM, Alexey Kuznetsov wrote: > Dmitriy, > > I like idea of passing clientID, how it should look? UUID? > I think Michael has suggested similar approach. I am not sure we need to pass the clientID with the message, given that we should know who

Re: Ignite-1.5 Release

Igniters, here is curernt status of platform/portable tickets. As I understand, IGNITE-950 is almost ready and will be merged very soon. There are 5 more tickets which depends on it: *IGNITE-1845*, *IGNITE-1846* - move portable API changes to .Net and C++. This is a matter of refacotring, should

Re: about apache ignite's document localization(Simplified Chinese)

Hi： My name is Yujue Li. Later I will send an email to dev-subscr...@ignite.apache.org. The reason for the link to be unable to open is a problem for the oschina code hosting platform,in the community, there have been people with similar problems,interested developers can try a few times. 在

Re: Prepared statement concept in indexing

Agree, it would be cool if we cache parsed queries without any changes to public API. But Dima, note that I saw this "20%" on local benchmark with only 1 node. I expect that in distributed environment it will be amortized by network. On Wed, Nov 4, 2015 at 6:00 PM, Sergi Vladykin

Re: Integration with Spring Transaction Manager

Hi Dmitriy, I want to give a try on this ticket. Could you assign it to me? Thanks.

Re: Questions about TeamCity CI organization

Hi Raul, I agree, we need to have the wiki page. Could you please initiate the one with topic which should be covered and provide a link? I will help with filling. Thanks, -- Artem -- On Tue, Nov 3, 2015 at 8:02 PM, Raul Kripalani wrote: > Hi Artem, > > Thanks for the

Re: Java 7 client using Java 7 server, or vice versa

Hi, This limitation has already been removed for the nearest release. If you work with Ignite sources then you can checkout the master branch that has the fix. Regards, Denis On 11/4/2015 1:14 PM, endian675 wrote: As mentioned on a post to the user list

[GitHub] ignite pull request: IGNITE-1854

GitHub user wmz7year opened a pull request: https://github.com/apache/ignite/pull/200 IGNITE-1854 You can merge this pull request into a Git repository by running: $ git pull https://github.com/wmz7year/ignite ignite-1854 Alternatively you can review and apply these

Java 7 client using Java 7 server, or vice versa

As mentioned on a post to the user list (http://apache-ignite-users.70518.x6.nabble.com/Mixing-Java-major-versions-on-client-server-td1380.html) it's not possible to connect a Java 7 client to a Java 8 server. Does anyone with intimate knowledge of the code know whether there are specific

Re: HTTP-REST sql query ID problem

We can use IgniteUuid qryId = IgniteUuid.fromUuid(clientId); and restrict page requests for queries submitted from other clients. I.e. throw exception if qryId.globalId() != clientId --Yakov 2015-11-04 12:21 GMT+03:00 endian675 : > Alexey, > > No problem, here is a link

Re: OSGi migration may require a special marshaller

Could we rewind a little bit please? What is the point of using the bundle symbolic name in the first place? In OSGi, it is bad practice to refer to bundles directly. A bundle is a packaging unit, that's all, but it should not have any further consideration. It is perfectly feasible that a given