July 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-332) Add ability to create GlobalConfiguration and DefaultConfiguration objects from XML files

by Noel O'Connor (JIRA)

Add ability to create GlobalConfiguration and DefaultConfiguration objects from XML files ------------------------------------------------------------------------------------------ Key: ISPN-332 URL: https://jira.jboss.org/jira/browse/ISPN-332 Project: Infinispan Issue Type: Feature Request Components: Configuration Reporter: Noel O'Connor Assignee: Noel O'Connor Priority: Minor -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-366) Document CAS-like operations in Hot Rod clearly

by Galder Zamarreno (JIRA)

Document CAS-like operations in Hot Rod clearly ----------------------------------------------- Key: ISPN-366 URL: https://jira.jboss.org/jira/browse/ISPN-366 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.Final <mmarkus_> galderz: ping <mmarkus_> what is the meaning of "replaceIfUnmodified"? * amontenegro_ (~amonteneg(a)200.111.187.74) has joined #infinispan * amontenegro_ is now known as aamonten * clebert (~clebert@redhat/jboss/clebert) has joined #infinispan * baileyje (~baileyje@redhat/jboss/baileyje) has joined #infinispan * clebert (~clebert@redhat/jboss/clebert) has left #infinispan <galderz> manik__, hi mmarkus_ <galderz> replaceIfUnmodified ? <galderz> one sec <galderz> mmarkus_, manik_, r u planning to produce diff jars for server and client? <galderz> if so, it'd make sense for the client to be a separate module <galderz> wouldn't it? <manik_> galderz: yes, I think diff jars would make sense <mmarkus_> galderz: i think yes, because I'd like the client to be light <galderz> same here <manik_> no one would want server code (+ server deps) on their client <galderz> exactly <galderz> so, the client should be in server/hotrod-client or similar module <mmarkus_> not sure we need another module for that, only different packaging <galderz> mmarkus_, u're lucky i don't have java classes <galderz> and u can use src/java <galderz> while I use main/scala <galderz> i mean, u use main/java <galderz> but once u give a maven module scala nature <galderz> i think it ignores main/java <galderz> at least that's what I found out doing some testing <mmarkus_> even so, can't we produce two jars for the same module? <galderz> mmarkus_, u prob can but u have to start filtering classes./..etc <manik_> mmarkus_: thats a real PITA <galderz> iow, it's a probably a PITA <manik_> try wrestling with maven assemblies to do that ! ;) <sannegrinovero> hi all; nice to see activity here :) hi galderz recovered from all the walking? <galderz> sannegrinovero, yup, fully recovered now :) <sannegrinovero> nice :) <manik_> mmarkus_: much easier to just use a separate maven module <mmarkus_> manik_: I don't want to do that for sure. Not a big fan o mvn (not to say more) <galderz> mmarkus_, replaceIfUnmodified is all about the cas <sannegrinovero> can't build the snapshot currently as I'm missing a jgroups:jar:2.10.0.Alpha2 <galderz> it's a way to do a replace remotely <galderz> u want to replace, only if no one changed the value <galderz> so what do u do? <galderz> each modification has a unique value associated to it <galderz> so, when u want to mayeb replace, u get the cas first with: getWithCas <galderz> and then use the cas to make the modification <sannegrinovero> galderz is this "replaceIfUnmodified" already in trunk? sounds very useful <galderz> if the cas values do not match, someone has changed the value and replace is not execited <galderz> sannegrinovero, not yet <sannegrinovero> ok <galderz> mmarkus_, it's the same technique used by memcached: see http://github.com/trondn/memcached/blob/master/doc/protocol.txt <galderz> see cas command in that document <galderz> cas is our replaceIfUnmodified <galderz> mmarkus_, is it clear? <mmarkus_> what is cas? <galderz> Compare And Swap <galderz> used all over java.util.concurrent <mmarkus_> I know that one, just I don't see how it maps in hotrod <mmarkus_> e.g. getWithCas? <galderz> mmarkus_, each modification has a unique value associated: <galderz> for example: <galderz> if u key=k value=v1, let's say the unique value is 12345 <galderz> get with cas returns that 12345 <galderz> 12345 and v1 of course <galderz> now, u call replaceIfUnmodified on key=k with value=v2 and cas 12345 <galderz> key=k will only be replaced by v2 if, and only if, the cas in that node is still 12345 <galderz> if someone else had made a modification in the mean time, the unique value would have changed <galderz> hence, replaceIfUnmodified call would not have succeded <galderz> mmarkus_, does it make sense now? <galderz> it's a way to do a remote CAS <galderz> as memcached says: " "cas" is a check and set operation which means "store this data but <galderz> only if no one else has updated since I last fetched it."" <mmarkus_> so cas is generated on the server, each modification to the cache (cluster) resulting in a new cas value? <galderz> that cas operation does exactly the same as replaceIfUnmodified <galderz> indeed mmarkus_ <galderz> see the memcached module for an example <galderz> we discussed this in the list as well <mmarkus_> is the cache set per key or per whole cache? <galderz> cas u mean? <galderz> it's associated with each value, so is per key <mmarkus_> cas, sorry <galderz> mmarkus_, see http://anonsvn.jboss.org/repos/infinispan/trunk/server/memcached/src/main... <galderz> and <galderz> AddCommand <galderz> or SetCommand <galderz> in memcached, we set it to current time millis <galderz> and we increment it for each modification <mmarkus_> yep, makes sense. And it's not returned by default, the only way to retrieve it is through getWithCas, right? <galderz> mmarkus_, indeed <mmarkus_> galderz: I'm just thinking, is there a way to do a put AND obtain the cas value atomically? * mmarkus_ i.e. the way I understand it. if one does a 1.put (k1,v1) <galderz> not at the moment <mmarkus_> then he will need to to a getWithCas(k1) to get this value back <galderz> i wonder how often this would be needed <galderz> indeed <galderz> by making getWithCas a separate command and not using cas anywhere, i'm assuming this is rare occurrence <galderz> but maybe it's not that rar <galderz> rare <mmarkus_> now, the cas he gets on getWithCas(k1), might be the cas of a different put that happened after put(k1,v1), e.g. put(k1,v2) <galderz> mmarkus_, well, that means someone has changed it then <galderz> i think i know what u mean though <galderz> if u have a put and replaceIfUnmodified one after the other, put returning the cas would cut one network call <mmarkus_> not necesarelly <mmarkus_> (that also) <galderz> i'm all ears :) <mmarkus_> considering your example with cas= 12345 (see few lines bellow) <mmarkus_> I do a put that results in cas 12345 <mmarkus_> then immediately after, one does another put(k), resulting in cas 54321 <mmarkus_> then you do an getWithCas and obtain cas=54321 on the server <mmarkus_> now you do a replaceIfUnmodified(k, 54321) <mmarkus_> the cas will match, and the replace operation will take place. But you really wanted it not to take place, as per your example, isn't it? <galderz> well, depends who does the getWithCas <galderz> or more specifically, who did the other put <galderz> what u know is that since u called getWithCas till u do replace, no one else has modified it <galderz> and that's what u do with cas <galderz> u get something, u check the value <mmarkus_> ah, you want to use cas for getting the following gurante: you read data, and based on what you read you want to modify it. Now you only modify it if it hasn't changed in between, correct? <galderz> it matches <galderz> indeed :) <galderz> that's what a cas does :) <galderz> u get something <galderz> u assume that it has X <mmarkus_> I see it now! <galderz> :) <mmarkus_> I was thinking at a different scenario. <mmarkus_> you put data, and at a further point you want to modify it only if it hasn't changed <mmarkus_> but, yeah, this doesn't sound as common as the other scenario, with read * aslak has quit (Quit: Ex-Chat) <mmarkus_> I got it now - thanks for the explanation! * manik_ has quit (Quit: manik_) <galderz> mmarkus_, u're welcome :) <galderz> we'll have to make sure this is explained properly in the docu <galderz> i'll add a jira -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-534) Standardise keys used for System properties, .properties and Properties entries

by Manik Surtani (JIRA)

Standardise keys used for System properties, .properties and Properties entries ------------------------------------------------------------------------------- Key: ISPN-534 URL: https://jira.jboss.org/browse/ISPN-534 Project: Infinispan Issue Type: Task Components: Configuration Affects Versions: 4.1.0.CR1 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR2, 4.1.0.Final I have seen a number of places in the codebase where we take in system parameters. In some cases this is to control certain unit test options such as: http://fisheye.jboss.org/browse/Infinispan/trunk/cachestore/jdbc/src/test... http://fisheye.jboss.org/browse/Infinispan/trunk/cachestore/cloud/src/int... http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/i... And in some cases these control runtime options such as: http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... http://fisheye.jboss.org/browse/Infinispan/trunk/server/rest/src/main/sca... http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/sca... And we occasionally use Properties to configure certain bits, such as certain Hot Rod and Memcached server options: http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/sca... And even Hot Rod client configs. http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src... And here are some examples of what the keys to these properties are: infinispan.jclouds.username infinispan.jdbc infinispan.tm infinispan.config.schema infinispan.server.rest.cfg program.name infinispan.server.host infinispan.hotrod-client.servers-default I would like to standardise on these a bit. It would (a) make it easier to document and (b) provide a greater level of consistency. So here is what I propose: * All system and property keys start with "infinispan." * Properties destined to control the way the test suite runs should have ".test." * The next bit should be the relevant affected module. E.g., ".server.hotrod." or ".server.rest." or ".client.hotrod.", or ".server." for stuff that is common across all server endpoints. * and the last bit could be descriptive to what the key controls. E.g., ".host". So, from above, the examples would look like: infinispan.test.cachestore.jclouds.username infinispan.test.cachestore.jdbc.driver infinispan.test.core.tm infinispan.core.config.schema infinispan.server.cfg (program.name? Don't know what this is... ) infinispan.server.host infinispan.client.hotrod.servers -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
1
0 / 0

[JBoss JIRA] Resolved: (ISPN-60) make cache XA compliant

by Mircea Markus (JIRA)

[ https://jira.jboss.org/browse/ISPN-60?page=com.atlassian.jira.plugin.syst... ] Mircea Markus resolved ISPN-60. ------------------------------- Resolution: Duplicate Issue covered by https://jira.jboss.org/browse/ISPN-272 > make cache XA compliant > ----------------------- > > Key: ISPN-60 > URL: https://jira.jboss.org/browse/ISPN-60 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > This should be implemented in order to bring failure-recovery capabilities to cache. Failure example: > Let's say that we have 3 nodes, A B and C. A starts tx, does a put ("k","v") then commits tx. During commit following happen: > 1) prepare is broadcasted > B prepares and holds locks > C prepares and holds locks > 2) A sees B and C voted okay,so triggers a commit: > - B receives the commit msg and applies changes (for good!) > - A does not manage to send the message to C *in the given timeout*. At this point, the RPC call returns and A rollbacks, also C will rollback after a while (tx timeout). But B will have the changes applied, and this will result in an atomicity being violated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-538) remove code duplication from HotRodOperationsImpl

by Mircea Markus (JIRA)

remove code duplication from HotRodOperationsImpl ------------------------------------------------- Key: ISPN-538 URL: https://jira.jboss.org/browse/ISPN-538 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani HotRodOperationsImpl - contain code duplication in the way retry is handled. Basically following logic is replicated through all operations: Transport transport = getTransport(key, true); int retryCount = 0; do { try { //to something here } catch (TransportException te) { logErrorAndThrowExceptionIfNeeded(retryCount, te); } finally { releaseTransport(transport); } if (shouldRetry(retryCount)) { transport = getTransport(key, false); } retryCount++; } while (shouldRetry(retryCount)); throw new IllegalStateException("We should not reach here!"); This should be factorized in a TemplateMethod because: a - duplication is evil and b - duplication is more even in a reference implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-532) HotRodMarshaller needs cleaning up!

by Manik Surtani (JIRA)

HotRodMarshaller needs cleaning up! ----------------------------------- Key: ISPN-532 URL: https://jira.jboss.org/browse/ISPN-532 Project: Infinispan Issue Type: Feature Request Components: Cache Server Affects Versions: 4.1.0.CR1 Reporter: Manik Surtani Assignee: Manik Surtani Priority: Blocker Fix For: 4.1.0.CR2, 4.1.0.Final I know this is late in the day, but it is crucial that this public API interface is cleaned up prior to final release. http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src... The 2 methods don't correspond to each other. This needs cleaning up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-241) improve test harness to use nice test names for nodes

by Mircea Markus (JIRA)

improve test harness to use nice test names for nodes ----------------------------------------------------- Key: ISPN-241 URL: https://jira.jboss.org/jira/browse/ISPN-241 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Priority: Minor Fix For: 4.0.0.GA all replicate caches are being created through a TestCacheManagerFactory, TestCacheManagerFactory would make sure to call TransportType.setNodeName on each cache -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-487) Log byte arrays partially in Hot Rod client

by Galder Zamarreno (JIRA)

Log byte arrays partially in Hot Rod client ------------------------------------------- Key: ISPN-487 URL: https://jira.jboss.org/browse/ISPN-487 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Mircea Markus Fix For: 4.1.0.CR1 In SerializationMarshaller I see this: if (log.isTraceEnabled()) { log.trace("Unmarshalled bytes: " + Arrays.toString(bytes) + " and returning object: " + o); } Using Arrays.toString() is Ok for most cases but if the serialized version is too big, it'd be hard to read trace logs. Instead, you should prob use a similar method to the one used by the HotRod/Memcached or when lazy deserialization is used where I call o.i.u.Util.printArray. This methods prints the byte array partially, only the first 10 bytes I believe, and if -Dinfinispan.arrays.debug=true is passed, it then prints the full array. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-478) Create a high level server modules wiki

by Galder Zamarreno (JIRA)

Create a high level server modules wiki --------------------------------------- Key: ISPN-478 URL: https://jira.jboss.org/browse/ISPN-478 Project: Infinispan Issue Type: Task Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR1 Create a high level server modules wiki inspired by http://community.jboss.org/message/543042#543042 and other pieces of information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-529) Improve release script to select where to tag from

by Galder Zamarreno (JIRA)

Improve release script to select where to tag from -------------------------------------------------- Key: ISPN-529 URL: https://jira.jboss.org/browse/ISPN-529 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreno Assignee: Manik Surtani Fix For: 4.1.0.CR2 Release script (release.py) currently tags of trunk Improve the script so that you can select where to tag from, i.e. branches/4.1.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2010