Re: [infinispan-dev] BoundedConcurrentHashMap

Hey Sanne, I implemented first versions of LIRS as Manik challenged me to implement it :-) This was back in early 2010. Then Will took over, simplified it and fixed some subtle bugs. Finally, Ban Manes took the whole thing over to Caffeine. Cheers, Vladimir On Thu, Jul 11, 2019 at 1:09 PM

Re: [infinispan-dev] Counters and their configurations in Infinispan server (DMR)

Hi everyone, Here is most of the implementation with example use outlined in https://github.com/infinispan/infinispan/pull/5570 Would you please review it as I am not an expert in DMR and I need one now :-) Regards, Vladimir On Fri, Nov 3, 2017 at 8:58 AM, Vladimir Blagojevic <vb

Re: [infinispan-dev] Counters and their configurations in Infinispan server (DMR)

reduce the learning curve if the user is already used to cli (i.e create caches). Cheers, Pedro On 02-11-2017 12:33, Vladimir Blagojevic wrote: Hey guys, How do you anticipate users are going to deal with counters? Are they going to be creating a lot of them in their applications, say dozens, hu

Re: [infinispan-dev] Replacing IRC

Some updates on memory issues we talked about https://slack.engineering/reducing-slacks-memory-footprint-4480fec7e8eb I looked at Stride briefly and it also looks very promising with its actions and decisions focus and deep integrations with Atlassian stack we use anyway! On 2017-10-16 8:45

[infinispan-dev] Infinispan 9.2.0Alpha1 has been released

Hey everyone, Our first release on Infinispan 9.2 branch is out. Read more about it at http://blog.infinispan.org/2017/10/infinispan-920alpha1-released.html Regards, Vladimir ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

[infinispan-dev] My weekly report

Guys, I am on PTO (March 6th-8th). Here is my weekly update: ISPN-7228 - Fixed a minor issue where an invalid schema got added anyway ISPN-7544 - Server cards do not indicate correct status in some cases All server states are properly indicated on the card now. We also adjusted an action menu

Re: [infinispan-dev] JGroups 4.0 released

Congratulations Bela. What a milestone! I was just counting - I can't believe it was almost 16 years ago that I first got introduced to JGroups. All the best, Vladimir On 2017-02-21 8:37 AM, Sanne Grinovero wrote: Congratulations! On 21 Feb 2017 12:21, "Bela Ban"

Re: [infinispan-dev] Cluster Executor failover and execution policy

Will, I like the API proposal but one thing that jumps out for me is to combine or rather overload singleNodeSubmission with singleNodeSubmission(int failOverCount) and remove failoverRetries method. The first singleNodeSubmission does not failover while the second one does with the

Re: [infinispan-dev] Infinispan Managment Console versioning and releases

Sebastian, Seems like you solved everything already on your own. Do you still have build issues? Vladimir On 2017-01-19 2:39 AM, Sebastian Laskawiec wrote: Just a friendly reminder... @Vladimir, @Ryan yes, I'm looking at YOU :) On Fri, Dec 16, 2016 at 9:22 AM, Sebastian Laskawiec

[infinispan-dev] Infinispan 8.2.3.Final and 9.0.0.Alpha3

Hey guys, Over the weekend we released Infinispan 9.0.0.Alpha3 and Infinispan 8.2.3.Final. Read more about it at http://blog.infinispan.org/2016/07/infinispan-900alpha3-and-823final.html All the best, Vladimir ___ infinispan-dev mailing list

Re: [infinispan-dev] Lambda Serialization

I think it does. If we document both approaches nicely *and* give examples then users can choose what suits them the most. Target user group of this API is likely very knowledgeable group of programmers anyway. On 2016-02-09 11:36 AM, William Burns wrote: I wanted to propose a pretty simple

[infinispan-dev] Infinispan 8.1.0.Alpha2 is out

Dear all, The second Alpha release of Infinispan 8.1 is now widely available. We have included the latest preview of the new admin console currently under heavy development. Using new admin console web application Infinispan server admins can now add new caches to a running domain server as

[infinispan-dev] Infinispan 7.2.2.Final is out

Hello everyone, We have released 7.2.2.Final today. This release does not include any new features, but it has resolutions for the minor bugs we have found since we released 7.2.1.Final. Please check outhttp://blog.infinispan.org for release notes, download links and additional

[infinispan-dev] [Web admin console] Which stats/metrics do you want to see?

Hellousers/admins, Which particular statistics/metrics do you want to see for caches and nodes in our new admin console we are developing [1]? We have created a wiki page [2] to hear your preferences. Your feedback is valuable and appreciated. Regards, Vladimir [1]

Re: [infinispan-dev] TopologySafe Map / Reduce

On 2014-10-10, 3:03 AM, Dan Berindei wrote: The problem is that the intermediate keys aren't in the same segment: we want the reduce phase to access only keys local to the reducing node, and keys in different input segments can yield values for the same intermediate key. So like you say,

Re: [infinispan-dev] Benchmarking Hadoop/Infinispan M/R implementation

Fernandes wrote: Yes, that would be interesting! Also, what do you think of running this benchmark on top of Infinispan native map-reduce implementation, to compare with Hadoop/HDFS and Hadoop/Infinispan? Gustavo On Thu, Jul 31, 2014 at 9:20 AM, Vladimir Blagojevic vblag...@redhat.com mailto:vblag

Re: [infinispan-dev] Infinispan 7.0.0.Alpha5 has been released

Should be fixed by now! Have a look again. Vladimir On 2014-07-18, 4:28 AM, Sanne Grinovero wrote: +1 There is still time to fix that by writing a blog post ;-) On 18 July 2014 09:19, Tristan Tarrant ttarr...@redhat.com wrote: Thanks Vladimir. A little note: instead of relying on Jira's

[infinispan-dev] Infinispan 7.0.0.Alpha5 has been released

Dear all, I am proud to announce that Infinispan 7.0.0.Alpha5 is out. There are numerous improvements and fixes included in this release. It is best to refer to release notes [1] for details. Regards, Vladimir [1]

Re: [infinispan-dev] Proposed ISPN 7 compilation incompatibilities with ISPN 6

Mircea and I wanted to promote AdvancedCacheLoader.KeyFilter or merge it with one filter we all choose to use because we have so many of these internal filter classes it is ridiculous. The filter you wrote is THE one? Vladimir On 3/13/2014, 8:35 AM, William Burns wrote: On Thu, Mar 13, 2014 at

Re: [infinispan-dev] Proposed ISPN 7 compilation incompatibilities with ISPN 6

On 3/13/2014, 11:39 AM, William Burns wrote: On Thu, Mar 13, 2014 at 11:14 AM, Vladimir Blagojevic vblag...@redhat.com wrote: Mircea and I wanted to promote AdvancedCacheLoader.KeyFilter or merge it with one filter we all choose to use because we have so many of these internal filter classes

Re: [infinispan-dev] Cluster Listeners 7.0.0.Alpha1

Very cool stuff Will! Just to clarify, one could define clustered listener, filter and converter and tie them all up together. Such a listener will be invoked when filter criteria is met, and converter converts key/value to some C object which is then sent of to listener, right? So how do you

Re: [infinispan-dev] Since it's almost Friday: the next code name for Infinispan

+1 Are you in Slovenia? On 3/5/2014, 10:26 AM, Bela Ban wrote: https://www.facebook.com/HumanFishBrewery ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] On the topic of Map/Reduce and Hadoop

Scala propaganda! :-) Thanks for sharing! On 2/27/2014, 9:23 AM, Galder Zamarreño wrote: Hi, Recently we had an email thread on Map/Reduce and Hadoop’s API/mechanisms to do Map/Reduce. I’ve just finished watching [1], which looks at Hadoop’s Java API and then looks at evolutions,

Re: [infinispan-dev] Distributed executors and Future(s) they return

be able to implement rescheduling or failover policies in future. Sanne On 26 February 2014 19:31, Vladimir Blagojevic vblag...@redhat.com wrote: Hey, There is an interesting request from community to include an Address along with a Future returned for a subtask being executed [1]. I

Re: [infinispan-dev] JavaDocs and API documentation

I agree, sounds like a sensible thing to do. But this needs to be planned carefully and when exactly is the good time to do it, soon and have it ready for 7.0.0.Final? On 2/26/2014, 10:29 AM, Dan Berindei wrote: If we move all internal classes to .impl sub-packages, it will be quite easy

[infinispan-dev] Distributed executors and Future(s) they return

Hey, There is an interesting request from community to include an Address along with a Future returned for a subtask being executed [1]. I think it makes sense what this user wants. We might create Future sub interface that has getAddress method and we can return an object implementing that

Re: [infinispan-dev] Further dist.exec and M/R API improvements

On 2/25/2014, 7:33 AM, Dan Berindei wrote: Do we really need special support for distributed tasks to write results to another cache? We already allow a task to do cache.getCacheManager().getCache(outputCache).put(k, v) Yeah, very good point Dan. Thanks for being sanity check. Mircea?

Re: [infinispan-dev] Further dist.exec and M/R API improvements

Hey, I am starting to like this thread more and more :-) In conclusion, for distributed executors we are not adding any new APIs because Callable implementers can already write to cache using existing API. We don't have to add any new elaborate callback/listener API either as users have not

Re: [infinispan-dev] Further dist.exec and M/R API improvements

See inline On 2/24/2014, 12:57 PM, Mircea Markus wrote: On Feb 19, 2014, at 8:45 PM, Vladimir Blagojevic vblag...@redhat.com wrote: Hey guys, As some of you might know we have received additional requirements from community and internally to add a few things to dist.executors and map/reduce

Re: [infinispan-dev] MapReduce limitations and suggestions.

On 2/19/2014, 8:22 AM, Dan Berindei wrote: Sorry, I didn't get too much from that example either, I gave up after the second registering is fun popup :) One last question: with Hadoop I imagine it's quite easy to leave the results of the M/R job on the distributed FS and start a new job

Re: [infinispan-dev] MapReduce limitations and suggestions.

On 2/19/2014, 12:43 PM, Dan Berindei wrote: This is on our todo list https://issues.jboss.org/browse/ISPN-4002 Cool, I thought I saw it somewhere but I didn't get to actually search in JIRA for it :) Vladimir, what do you think about the partitioning/sorting/grouping stuff? I'm not

[infinispan-dev] Further dist.exec and M/R API improvements

Hey guys, As some of you might know we have received additional requirements from community and internally to add a few things to dist.executors and map/reduce API. On distributed executors front we need to enable distributed executors to store results into cache directly rather than

Re: [infinispan-dev] MapReduce limitations and suggestions.

On 2/18/2014, 4:59 AM, Dan Berindei wrote: The limitation we have now is that in the reduce phase, the entire list of values for one intermediate key must be in memory at once. I think Hadoop only loads a block of intermediate values in memory at once, and can even sort the intermediate

Re: [infinispan-dev] MapReduce limitations and suggestions.

Tristan, Actually they are not addressed in this pull request but the feature where custom output cache is used instead of results being returned is next in the implementation pipeline. Evangelos, indeed, depending on a reducer function all intermediate KOut/VOut pairs might be moved to a

Re: [infinispan-dev] 7.0.0.Alpha1

Mircea, ISPN-2284 has not been integrated yet. Dan and Will gave me some really good feedback that resulted in additional fixes, further explicit testing of parallel execution. I think we have it ready for integration now. Regards, Vladimir On 2/7/2014, 2:44 PM, Mircea Markus wrote: Hey

Re: [infinispan-dev] reusing infinispan's marshalling

Not 100% related to what you are asking about but have a look at this post and the discussion that erupted: http://gridgain.blogspot.ca/2012/12/java-serialization-good-fast-and-faster.html Vladimir On 1/30/2014, 7:13 AM, Adrian Nistor wrote: Hi list! I've been pondering about re-using the

Re: [infinispan-dev] Parallel M/R

On 12/6/2013, 11:40 AM, Mircea Markus wrote: Hmm I think you could leverage the parallel iteration from the EquivalentConcurrentHashMapV8 there instead of writing it yourself ;) Hi, for those interested in parallel M/R I have uploaded my first proposal that will hopefully, with your input,

Re: [infinispan-dev] Parallel M/R

Radim, these are some very good ideas. And I think we should put them on the roadmap. Also, I like your ExecutorAllCompletionService, however, I think it will not work in this case as we often do not have exclusive access to the underlying executor service used in ExecutorAllCompletionService.

Re: [infinispan-dev] Parallel M/R

the entries, which already supports parallel iteration so the heavy lifting is already in place On Dec 4, 2013, at 5:16 PM, Vladimir Blagojevic vblag...@redhat.com wrote: Here is my M/R parallel execution solution updated to master https://github.com/vblagoje/infinispan/tree/t_2284_new Now

Re: [infinispan-dev] Parallel M/R

Hey Mircea, On 12/6/2013, 11:40 AM, Mircea Markus wrote: Ah right. Still for each key an StatelessTask instance is created though. I don't think this is the case. There is one StatelessTask per map/reduce/combine invocation. What I intend to do is move this code to DataContainer because the

Re: [infinispan-dev] HotRod C++ client 6.0.0.Final announcement

Awesome! Great team effort guys! I am proud how we pulled this one off! Vladimir On 11/21/2013, 4:45 AM, Tristan Tarrant wrote: http://blog.infinispan.org/2013/11/infinispan-hotrod-c-client-600final.html ___ infinispan-dev mailing list

Re: [infinispan-dev] Infinispan 6.0.0.Final is out!

On 11/20/2013, 10:30 AM, Adrian Nistor wrote: Thanks Manik! Website rendering and twitter are fixed now. Adrian, I made a mistake with source highlighter for c++. It worked locally for me but I believe these highlighters are version dependent. I am pushing a PR now that should fix it. Lets

[infinispan-dev] Documentation writing - grammar correction

Hey guys, Since I am working on API docs for HotRod C++ client, and I notice a stronger push for better documentation in general, I was wondering if we can maybe get an account with one of these grammar correction software services? We only have William on our team who is native English

[infinispan-dev] Infinispan 6.0.0.Beta2 is released!

Dear Infinispan community, Staying committed to the software development philosophy of Release early. Release often. And listen to your customers we are releasing Infinispan 6.0.0.Beta2 today. This is mainly a stabilization release after a flurry of new features released in Beta1. The Beta2

[infinispan-dev] Infinispan 6.0.0.Beta2 release is tomorrow (Friday Sept 27th)

Guys, Please have a look at outstanding issues for Beta2 at http://goo.gl/nS4EuV The target time to start the release is 9am EST which should be almost end of the day in Europe - so please have your PRs reviewed and ready for integration by then. I just spoke with Adrian, Dan and Mircea who

Re: [infinispan-dev] blog on new cache store API

Shane, When MapReduce command arrives on the Infinispan node it is execute on a single thread that carries the incoming message. I have done preliminary work on multithreaded execution [1] but I have not get around to complete it. The main idea is that incoming thread submits a task to

Re: [infinispan-dev] ApplyDeltaCommand: question about affected keys

On 13-01-23 2:01 PM, Pedro Ruivo wrote: Hi all, I was looking in the ApplyDeltaCommand code and I found something strange. Why is the method getAffectedKeys() returning a singleton collection with a null key inside? Yes, this is a bug. It should return s single key where delta map is stored.

Re: [infinispan-dev] ApplyDeltaCommand: question about affected keys

On 13-01-25 6:09 AM, Adrian Nistor wrote: Hi Vladimir, I think Pedro's initial question remained unanswered. Would be good to clarify this so we can fix the TODO in ApplyDeltaCommand constructor. Thanks, Adrian AdrianPedro, Yes, good catch. It should be passed to super as you noted. But

Re: [infinispan-dev] StoreByValueTest tck test

On 13-01-28 6:56 AM, Manik Surtani wrote: Now lets consider what JSR 107 needs. Similarly named, the feature in JSR 107 serves a completely different purpose, and this is referential integrity. Think database-style isolation (repeatable read, etc) where concurrent threads holding object

Re: [infinispan-dev] Translating our events to JSR 107 events

On 13-01-28 3:11 AM, Dan Berindei wrote: On 25 Jan 2013 23:26, Vladimir Blagojevic vblag...@redhat.com mailto:vblag...@redhat.com wrote: Hey, I figured out why cache listeners notifications were not fired. We have to add listener *after* cache.start() has been called. If listener

Re: [infinispan-dev] Translating our events to JSR 107 events

On 13-01-28 7:31 AM, Manik Surtani wrote: If you're ok with changing the core, you could add a getValue() method to CacheEntryCreatedEvent, and an isCreated() method to CacheEntryModifiedEvent (as I suppose you don't want to call the updates listener when an entry is created). Both changes

Re: [infinispan-dev] Map/Reduce Tasks and classpath

Yes it does! On 13-01-25 4:31 PM, Ray Tsang wrote: For Map/Reduce tasks - does the Task, Mapper, Reducer implementations classes need to be present in the classpath of all the nodes? Thanks, ___ infinispan-dev mailing list

[infinispan-dev] Translating our events to JSR 107 events

Hey, I figured out why cache listeners notifications were not fired. We have to add listener *after* cache.start() has been called. If listener is added before start it will not be registered. That aside I found some problems mapping our events to jsr 107 events. The problem is specifically

Re: [infinispan-dev] StoreByValueTest tck test

this without some extra configuration option. Cheers, On Jan 23, 2013, at 5:38 PM, Vladimir Blagojevic vblag...@redhat.com wrote: Galder, A quick search of help from you beacuse you are more familiar with this area (storeAsBinary) than I am. There is a tck test that checks storing of objects

Re: [infinispan-dev] ApplyDeltaCommand: question about affected keys

this is what you guys are looking for. https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/commands/write/PutKeyValueCommand.java#L100 On 23 Jan 2013, at 21:02, Vladimir Blagojevic vblag...@redhat.com mailto:vblag...@redhat.com wrote

Re: [infinispan-dev] ApplyDeltaCommand: question about affected keys

On 13-01-24 12:52 PM, Randall Hauch wrote: Actually, it is both, depending upon the situation. When a new process is started and joins the cluster, the new process will via state transfer receive its entries as externalized whole values, not deltas. However, from that point forward, I believe

Re: [infinispan-dev] ApplyDeltaCommand: question about affected keys

On 13-01-23 3:36 PM, Ray Tsang wrote: speaking of ApplyDeltaCommand - where does it actually perform the delta operation? perform() simply returns null. Any pointers? Thanks, Look for use of ApplyDeltaCommand class in IDE (in Eclipse highlight class name + right click +

Re: [infinispan-dev] dist exec draining thread pool

On 13-01-08 2:58 PM, Mircea Markus wrote: On 8 Jan 2013, at 14:00, Ales Justin wrote: Invoking a few how many tasks? The Executor that rejects the task is configured externally. If 3 threads are not enough you should either increase the number of threads or use a different rejection

Re: [infinispan-dev] Fwd: infinispan NPE

Hmm, looking into this. Thanks Ales! On 13-01-03 9:32 PM, Ales Justin wrote: @Vladimir: any idea why the NPE? OpenShift only, it occurs on a sequence of requests with no delay between them. Matej. On 03/01/13 20:58, Ales Justin wrote: Can you reproduce this locally? Or OpenShift

Re: [infinispan-dev] Fwd: infinispan NPE

Ales, I am totally puzzled how is this possible, never seen it before. In order for DefaultExecutorService to fail on line 950 with NPE, the underlying Future field of DistributedTaskPart has to be set to null. Future field is set only in two places, if task is executed locally [1] or

Re: [infinispan-dev] Separate ExecutorService for map/reduce tasks?

On 12-12-05 10:53 AM, Tristan Tarrant wrote: Yes. Ideally I would like to have: GlobalConfigurationBuilder global = new GlobalConfigurationBuilder(); global .addExecutor().name(blah); .addScheduledExecutor().name(sched); Configuration config = new Configuration(); config

Re: [infinispan-dev] Separate ExecutorService for map/reduce tasks?

On 12-12-05 5:07 AM, Mircea Markus wrote: On 5 Dec 2012, at 08:36, Tristan Tarrant wrote: In 6.0 I would really like to go away from the current executor configuration (e.g. a specific element for every executor) and allow the creation of named executors (this is how the AS configuration

[infinispan-dev] Commons-lang dependency

Hi, I see that we already use some commons-xyz libs and I was wondering if we can introduce commons-lang lib dependency in our code? I found their implementation of ExceptionUtils pretty solid and I would like to use [1]. There are other useful classes as well and the jar should not be too

[infinispan-dev] Separate ExecutorService for map/reduce tasks?

Hi, Although https://issues.jboss.org/browse/ISPN-2284 is charted for 6.0 I would like to see if there is a possibility to finish it for 5.2. Most of the parallel execution I have done already this and last week [1]. However, this change is not limited to map/reduce package only as we might

Re: [infinispan-dev] Transaction table cleanup

On 12-10-29 8:49 PM, Manik Surtani wrote: On 19 Oct 2012, at 17:40, Mircea Markus mircea.mar...@jboss.com mailto:mircea.mar...@jboss.com wrote: On 19 Oct 2012, at 07:41, Vladimir Blagojevic wrote: On 12-10-19 4:15 AM, Manik Surtani wrote: You're right actually, the temporary cache

[infinispan-dev] Unit test PR for master

Hi, I noticed that we recently have had many PR for unit tests integration into master. Would it not make more sense to integrate unit tests with actual fixes rather than having them merged directly to master as PRs? I'd say leave a unit test attached/referenced in JIRA and a

Re: [infinispan-dev] Unit test PR for master

not sure I understood you. are these pulls you mention having failing tests? I've sent a test related PR yesterday which was just changing a single test from using deprecated code to new code, there is nothing to fix. Sanne On 25 October 2012 15:52, Vladimir Blagojevic vblag...@redhat.com

Re: [infinispan-dev] infinispan 5.2.0.Beta3

On 12-10-25 12:37 PM, Mircea Markus wrote: Hi, We have a lot of pull requests pending. Until Beta3 is released, can we please focus on these and slow down the development for now. I've grouped them as follows. Please feel free to shuffle them around/ ask for more feedback if you think

Re: [infinispan-dev] Dist.exec failover

On 12-10-23 12:42 PM, Erik Salter wrote: Incidentally, the failover policy obscures the original reason the task failed. The exception thrown to the calling node is a FailoverException. The original reason is about 4 levels deep. Example: We have the best QA team :-)

Re: [infinispan-dev] Dist.exec failover

On 12-10-23 12:56 PM, Mircea Markus wrote: On 23 Oct 2012, at 17:54, Manik Surtani wrote: On 23 Oct 2012, at 17:17, Vladimir Blagojevic vblag...@redhat.com mailto:vblag...@redhat.com wrote: On 12-10-23 11:40 AM, Mircea Markus wrote: The main reason for passing the keys is in order

[infinispan-dev] Dist.exec failover

Hey guys, Erik noted that we should by default have no failover policy installed rather the default random policy we currently have. Also he noted that keys are never supplied to failover policy and they might be important when it comes to a deciding where to dispatch the failed over task.

Re: [infinispan-dev] Cache stopping

On 12-10-19 9:33 AM, Galder Zamarreño wrote: Extending to dev list... Galder, Thanks for your response. Since we talked I've traced this to TransactionTable and removal of remote tx from it. See TransactionTable cleanup thread. Cheers, Vladimir ___

Re: [infinispan-dev] Transaction table cleanup

On 12-10-19 4:15 AM, Manik Surtani wrote: You're right actually, the temporary cache created is transactional. it is built in the CreateCacheCommand and relies on the DummyTransactionManager, might be better to use batching perhaps? Or even not require for this cache to be transactional?

Re: [infinispan-dev] Avoid Collections.emptySet() / emptyMap() / emptyList

Cool! Did not know about this! Is this original idea or others are already doing this? On 12-10-19 8:31 AM, Galder Zamarreño wrote: Hi all, Re: https://github.com/galderz/infinispan/commit/0609207d13216de81d77ff51dc20652ce270c635 Please avoid using these JDK methods where possible. I've

[infinispan-dev] Transaction table cleanup

Hey guys, Investigating why EmbeddedCacheManager#cacheRemove hiccups DistributedTwoNodesMapReduceTest. As you might recall upon end of MapReduceTask there is EmbeddedCacheManager#cacheRemove call to remove intermediate caches across the cluster. Very often, almost every test run, execution of

Re: [infinispan-dev] Map/Reduce test failures in master

Been already investigating Manik :-) See Transaction table cleanup thread. Cheers, Vladimir On 12-10-18 9:04 AM, Manik Surtani wrote: Guys (probably Vladimir) Does anyone know what's up here? I see these fail sporadically: Failed tests:

Re: [infinispan-dev] NPE in MapReduceTask running in cluster

Ok, I recommend closing of https://issues.jboss.org/browse/ISPN-2353 to project lead! This startup issue will be addressed separately I am sure. On 12-10-01 8:02 AM, Thomas Fromm wrote: Am 30.09.2012 23:08, schrieb Matej Lazar: NPE was caused by not configured/started cache on the second node.

Re: [infinispan-dev] Command cancellation

) ? - Manik On 21 Sep 2012, at 11:42, Vladimir Blagojevic vblag...@redhat.com mailto:vblag...@redhat.com wrote: Hi, I wanted to run by you guys design of command cancellation Manik and I talked about recently. For more background regarding this task read https://issues.jboss.org/browse/ISPN-1042

Re: [infinispan-dev] NPE in MapReduceTask running in cluster

https://issues.jboss.org/browse/ISPN-2353 On 12-09-27 1:47 PM, Matej Lazar wrote: NPE ocures while running CapeDwarf cluster tests, see stack below. Null comes from MapReduceTask.invokeEverywhere 13:36:51,053 INFO [org.jboss.as.clustering.infinispan] (http-/192.168.30.248:8080-1)

Re: [infinispan-dev] 5.2.0.Beta1

On 12-09-21 7:07 PM, Sanne Grinovero wrote: Most of Sanne/Galder's query related changes are resolved; it still needs: - some bugfixes, especially Luksa's pull request is important - the MassIndexer is integrated, but the be effective it needs Vladimir's changes to have Map/Reduce split the

Re: [infinispan-dev] Command cancellation

On 12-09-21 2:34 PM, Manik Surtani wrote: Looks good, except that the pseudocode for dealing with a CancellableCommand (on the recipient node) should look like: * Receive command * if CancellableCommand, register with CancellationService * Perform command * If CancellableCommand, un-register

Re: [infinispan-dev] Command cancellation

I agree with you guys! Having said that, I am with Manik on this as I also think that infrastructure I plan to build for ISPN-1042 can be expanded and adapted to generic command cancellation once we have identified all requirements needed ( as you have pointed out some of these Dan). On

[infinispan-dev] Command cancellation

Hi, I wanted to run by you guys design of command cancellation Manik and I talked about recently. For more background regarding this task read https://issues.jboss.org/browse/ISPN-1042 At originating node I would have each Cancellable command create its UUID as part of constructor. After that

Re: [infinispan-dev] Command cancellation

* If CancellableCommand, un-register from CancellationService That last step was missing from your detail below. I presume that would require a CancellationService#unregisterThread(UUID u) ? - Manik On 21 Sep 2012, at 11:42, Vladimir Blagojevic vblag...@redhat.com mailto:vblag...@redhat.com wrote

[infinispan-dev] Running CDI test suite

Guys, As I prepared pull request for ISPN-2181 and I rebased to current master, my cdi test suite started to fail with: -- T E S T S --- Running TestSuite Configuring TestNG with:

Re: [infinispan-dev] Running CDI test suite

AM, Vladimir Blagojevic wrote: Guys, As I prepared pull request for ISPN-2181 and I rebased to current master, my cdi test suite started to fail with: -- T E S T S --- Running

Re: [infinispan-dev] Running CDI test suite

Confirmed. We can fix this issue by using XmlTest#getXmlClasses instead of XmlTest#getClasses in UnitTestTestNGListener. I'll issue a pull for this simple fix. On 12-09-05 12:24 PM, Vladimir Blagojevic wrote: Ok looks like someone updated UnitTestTestNGListener.java from core project to use

Re: [infinispan-dev] Running CDI test suite

, is there any reason why the CDI test suite doesn't use the same TestNG version as the core test suite? BTW, the latest TestNG version is 6.7, we might want to consider an upgrade for all the projects. On Wed, Sep 5, 2012 at 2:29 PM, Vladimir Blagojevic vblag...@redhat.com

[infinispan-dev] Are user classes/objects stored as MarshalledValues in AS?

Galder and others, Need some help! I am looking at https://issues.jboss.org/browse/ISPN-2138 and trying to understand what is going on! I tried example in ISPN-2138 and I confirmed the findings. It must be that TestEntry instances put in cache are stored as MarshalledValues! If I try the same

Re: [infinispan-dev] Map/Reduce enhancements with ISPN-2037

, 2012, at 8:13 PM, Vladimir Blagojevic wrote: Guys, I believe I finished ISPN-2037 that Sanne needed for his queries. However, adding ISPN-2037 commit to current master involves injection of CacheLoaderManager into MapReduceCommand. That solution is pretty ugly and we are switching soon

Re: [infinispan-dev] Map/Reduce enhancements with ISPN-2037

PM, Vladimir Blagojevic wrote: Guys, I believe I finished ISPN-2037 that Sanne needed for his queries. However, adding ISPN-2037 commit to current master involves injection of CacheLoaderManager into MapReduceCommand. That solution is pretty ugly and we are switching soon to a new map/reduce

Re: [infinispan-dev] X-S replication configuration

On 12-07-12 8:47 AM, Mircea Markus wrote: On 10 Jul 2012, at 18:28, Galder Zamarreño wrote: And line 25: backups instead of sites Same here. I would keep sites in global definition and backups in caches. But either way is good, matter of taste! ___

[infinispan-dev] Map/Reduce enhancements with ISPN-2037

Guys, I believe I finished ISPN-2037 that Sanne needed for his queries. However, adding ISPN-2037 commit to current master involves injection of CacheLoaderManager into MapReduceCommand. That solution is pretty ugly and we are switching soon to a new map/reduce implementation anyway. Going in

Re: [infinispan-dev] Optimizing tx for DIST from user perspective

On 12-07-09 3:31 AM, Mircea Markus wrote: we use key's CH value to induce an order over the keys written in a transaction - that's in order to avoid deadlocks. If there are collisions between these values then there's still a chance for deadlock. Mircea, I looked at

Re: [infinispan-dev] Optimizing tx for DIST from user perspective

Mircea, First of all thanks for the feedback! Your ideas and pointers are appreciated as always! On 12-07-10 7:02 AM, Galder Zamarreño wrote: Before blogging, it would it be good do some testing to measure the performance boost with some sampled data? The advantage of doing this, apart

Re: [infinispan-dev] Finding unused dependecies in infinispan distribution zip

On 12-06-18 10:42 AM, Manik Surtani wrote: Everyone, please have a look and confirm that all of the dependencies here are actually necessary in each module. What are these woodstox libraries used for in core? Can not find them in our code as compile dependencies?

[infinispan-dev] New Map/Reduce preview

Guys, I have implemented the initial version of the new, more scalable, and robust Map/Reduce solution originally described in the design document https://community.jboss.org/wiki/Infinispan60-MapReduceEnhancements If you are interested have a look at

Re: [infinispan-dev] Map Reduce 2.0

On 12-06-08 10:47 AM, Manik Surtani wrote: Cool. Are you working on this now? How long do you reckon before we can unleash it on the public? ;) Well I wanted to start early, gather feedback in a few iterations and have it ready for 6.0. Currently, I am half way through implementing

Re: [infinispan-dev] Map Reduce 2.0

On 12-06-01 4:49 AM, Manik Surtani wrote: We should update the interface then to indicate how you intend to make the ExecutorService made available to implementations. :) We can provide setDistributedExecutorService(DistributedExecutorService service) method on DistributedTaskFailoverPolicy

Re: [infinispan-dev] Map Reduce 2.0

On 12-05-31 10:06 AM, Manik Surtani wrote: Some thoughts: 1. Failover policy. * Does this rely on being run in a CDI environment? (RandomNodeTaskFailoverPolicy has a DistributedExecutorService @Injected). If so, then -1. While it *should work* in a CDI environment, it shouldn't

  1   2   >