June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3181) Retrieving entries via REST doesn't work

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3181?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-3181: ------------------------------------- Not sure how to handle this cos users can still configure REPEATABLE_READ in the server. Maybe the server should throw a warning when setting this or this configuration option should be removed altogether. > Retrieving entries via REST doesn't work > ---------------------------------------- > > Key: ISPN-3181 > URL: https://issues.jboss.org/browse/ISPN-3181 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Attachments: console_output.txt, server.log, standalone-dist.xml > > > Retrieving an entry stored via REST fails with 404 http response. > The test is located here: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests.... > {code:java} > String fullPathKey = fullPathKey(KEY_A); > post(fullPathKey, "data", "application/text"); > HttpResponse resp = get(fullPathKey, "data"); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3181) Retrieving entries via REST doesn't work

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3181?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-3181: ------------------------------------- This problem with Scala match error on RepeatableReadEntry entries is known to developers. Galder considered this a minor issue as REPEATABLE_READ locking only makes sense when using transactions and transactions are not supported in the server. This issue does not appear when setting READ_COMMITED locking. > Retrieving entries via REST doesn't work > ---------------------------------------- > > Key: ISPN-3181 > URL: https://issues.jboss.org/browse/ISPN-3181 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Attachments: console_output.txt, server.log, standalone-dist.xml > > > Retrieving an entry stored via REST fails with 404 http response. > The test is located here: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests.... > {code:java} > String fullPathKey = fullPathKey(KEY_A); > post(fullPathKey, "data", "application/text"); > HttpResponse resp = get(fullPathKey, "data"); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3215) Improve message routing for PutMapCommand for non transactional caches

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3215?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3215: ----------------------------------- [~mircea.markus]: It's a multicast message, therefore, it is processed on every node - in the end it may end up with nop if the node does not contain any of the keys as secondary owner, but before that it must bubble up through JGroups stack, enter some processing in Infinispan etc. > Improve message routing for PutMapCommand for non transactional caches > ---------------------------------------------------------------------- > > Key: ISPN-3215 > URL: https://issues.jboss.org/browse/ISPN-3215 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Radim Vansa > Assignee: Mircea Markus > > Current implementation: > A wants to execute PutMapCommand with many keys - let's assume that in fact the keys span all nodes in the cluster. > 1. A locks all local keys and sends via unicast a message to each primary owner of some of the keys in the map > 2. A sends unicast message to each node, requesting the operation > 3. Each node locks its keys and sends multicast message to ALL other nodes in the cluster > This happens N - 1 times: > 4. Each node receives the multicast message, (updates the non-primary segments) and sends reply back to the sender of mcast message. > 5. The primary owners send confirmation back to A. > Let's compute how many messages are here received - it's > N - 1 // A's request > (N - 1) * (N - 1) // multicast message received > (N - 1) * (N - 1) // reply to the multicast message received > N - 1 // response to A > That's 2*N^2 - 2*N messages. In case nobody needs flow control replenishments, nothing is lost etc. That ^2 exponent does not look like the cluster is really scaling. > Could the requestor orchestrate the whole operation? The idea is that all messages are sent only between requestor and other nodes, never between the other nodes. The requestor would lock the primary keys by one set of messages (waiting for reply), updating the non-primaries by another set of messages and then again unlocking all primaries by last message. > The set of messages could be either unicast with selected keys only for the recipient, or multicast with whole map - rationalization which one is actually better is subject to performance test. > This results in 6*N - 6 messages (or 5*N - 5 if the last message wouldn't require the reply). You can easily see when 5*(N - 1) is better than 2*N*(N - 1). > Or is this too similar to transactions with multiple keys? > I think that with current implementation, the putAll operation should be discouraged as it does not provide better performance than multiple put (and in terms of atomicity it's probably not much better either). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3215) Improve message routing for PutMapCommand for non transactional caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3215?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3215: ------------------------------------- {quote}3. Each node locks its keys and sends multicast message to ALL other nodes in the cluster{quote} It doesn't send an multicast to all the members in the cluster, but only to the secondary owners. Indeed in the case of replicated caches, this is the entire cluster. > Improve message routing for PutMapCommand for non transactional caches > ---------------------------------------------------------------------- > > Key: ISPN-3215 > URL: https://issues.jboss.org/browse/ISPN-3215 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Radim Vansa > Assignee: Mircea Markus > > Current implementation: > A wants to execute PutMapCommand with many keys - let's assume that in fact the keys span all nodes in the cluster. > 1. A locks all local keys and sends via unicast a message to each primary owner of some of the keys in the map > 2. A sends unicast message to each node, requesting the operation > 3. Each node locks its keys and sends multicast message to ALL other nodes in the cluster > This happens N - 1 times: > 4. Each node receives the multicast message, (updates the non-primary segments) and sends reply back to the sender of mcast message. > 5. The primary owners send confirmation back to A. > Let's compute how many messages are here received - it's > N - 1 // A's request > (N - 1) * (N - 1) // multicast message received > (N - 1) * (N - 1) // reply to the multicast message received > N - 1 // response to A > That's 2*N^2 - 2*N messages. In case nobody needs flow control replenishments, nothing is lost etc. That ^2 exponent does not look like the cluster is really scaling. > Could the requestor orchestrate the whole operation? The idea is that all messages are sent only between requestor and other nodes, never between the other nodes. The requestor would lock the primary keys by one set of messages (waiting for reply), updating the non-primaries by another set of messages and then again unlocking all primaries by last message. > The set of messages could be either unicast with selected keys only for the recipient, or multicast with whole map - rationalization which one is actually better is subject to performance test. > This results in 6*N - 6 messages (or 5*N - 5 if the last message wouldn't require the reply). You can easily see when 5*(N - 1) is better than 2*N*(N - 1). > Or is this too similar to transactions with multiple keys? > I think that with current implementation, the putAll operation should be discouraged as it does not provide better performance than multiple put (and in terms of atomicity it's probably not much better either). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3215) Improve message routing for PutMapCommand for non transactional caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3215?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3215: -------------------------------- Summary: Improve message routing for PutMapCommand for non transactional caches (was: Improve message routing for PutMapCommand) > Improve message routing for PutMapCommand for non transactional caches > ---------------------------------------------------------------------- > > Key: ISPN-3215 > URL: https://issues.jboss.org/browse/ISPN-3215 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Radim Vansa > Assignee: Mircea Markus > > Current implementation: > A wants to execute PutMapCommand with many keys - let's assume that in fact the keys span all nodes in the cluster. > 1. A locks all local keys and sends via unicast a message to each primary owner of some of the keys in the map > 2. A sends unicast message to each node, requesting the operation > 3. Each node locks its keys and sends multicast message to ALL other nodes in the cluster > This happens N - 1 times: > 4. Each node receives the multicast message, (updates the non-primary segments) and sends reply back to the sender of mcast message. > 5. The primary owners send confirmation back to A. > Let's compute how many messages are here received - it's > N - 1 // A's request > (N - 1) * (N - 1) // multicast message received > (N - 1) * (N - 1) // reply to the multicast message received > N - 1 // response to A > That's 2*N^2 - 2*N messages. In case nobody needs flow control replenishments, nothing is lost etc. That ^2 exponent does not look like the cluster is really scaling. > Could the requestor orchestrate the whole operation? The idea is that all messages are sent only between requestor and other nodes, never between the other nodes. The requestor would lock the primary keys by one set of messages (waiting for reply), updating the non-primaries by another set of messages and then again unlocking all primaries by last message. > The set of messages could be either unicast with selected keys only for the recipient, or multicast with whole map - rationalization which one is actually better is subject to performance test. > This results in 6*N - 6 messages (or 5*N - 5 if the last message wouldn't require the reply). You can easily see when 5*(N - 1) is better than 2*N*(N - 1). > Or is this too similar to transactions with multiple keys? > I think that with current implementation, the putAll operation should be discouraged as it does not provide better performance than multiple put (and in terms of atomicity it's probably not much better either). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3213) Upgrade to JCache 0.7

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3213?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3213: ---------------------------------------- Can be worked around by adding the following to the TCK Runner's Surefire settings: {code}<jvm>${env.JAVA_HOME_7}/bin/java</jvm>{code} Everyone will need to define JAVA_HOME_7 in their environment to fully build though. > Upgrade to JCache 0.7 > --------------------- > > Key: ISPN-3213 > URL: https://issues.jboss.org/browse/ISPN-3213 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR2, 5.3.0.Final > > > Upgrade to JCache 0.7 (https://groups.google.com/forum/#!topic/jsr107/vYRLv2xsveA) and see if issues WRT annotation integration highlighted in ISPN-2855 are fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3213) Upgrade to JCache 0.7

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3213?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3213: ---------------------------------------- Hmmmm, the 0.7 TCK requires Java 7 to run: https://github.com/jsr107/jsr107tck/issues/16 > Upgrade to JCache 0.7 > --------------------- > > Key: ISPN-3213 > URL: https://issues.jboss.org/browse/ISPN-3213 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR2, 5.3.0.Final > > > Upgrade to JCache 0.7 (https://groups.google.com/forum/#!topic/jsr107/vYRLv2xsveA) and see if issues WRT annotation integration highlighted in ISPN-2855 are fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3215) Improve message routing for PutMapCommand

by Radim Vansa (JIRA)

Radim Vansa created ISPN-3215: --------------------------------- Summary: Improve message routing for PutMapCommand Key: ISPN-3215 URL: https://issues.jboss.org/browse/ISPN-3215 Project: Infinispan Issue Type: Enhancement Components: Core API Reporter: Radim Vansa Assignee: Mircea Markus Current implementation: A wants to execute PutMapCommand with many keys - let's assume that in fact the keys span all nodes in the cluster. 1. A locks all local keys and sends via unicast a message to each primary owner of some of the keys in the map 2. A sends unicast message to each node, requesting the operation 3. Each node locks its keys and sends multicast message to ALL other nodes in the cluster This happens N - 1 times: 4. Each node receives the multicast message, (updates the non-primary segments) and sends reply back to the sender of mcast message. 5. The primary owners send confirmation back to A. Let's compute how many messages are here received - it's N - 1 // A's request (N - 1) * (N - 1) // multicast message received (N - 1) * (N - 1) // reply to the multicast message received N - 1 // response to A That's 2*N^2 - 2*N messages. In case nobody needs flow control replenishments, nothing is lost etc. That ^2 exponent does not look like the cluster is really scaling. Could the requestor orchestrate the whole operation? The idea is that all messages are sent only between requestor and other nodes, never between the other nodes. The requestor would lock the primary keys by one set of messages (waiting for reply), updating the non-primaries by another set of messages and then again unlocking all primaries by last message. The set of messages could be either unicast with selected keys only for the recipient, or multicast with whole map - rationalization which one is actually better is subject to performance test. This results in 6*N - 6 messages (or 5*N - 5 if the last message wouldn't require the reply). You can easily see when 5*(N - 1) is better than 2*N*(N - 1). Or is this too similar to transactions with multiple keys? I think that with current implementation, the putAll operation should be discouraged as it does not provide better performance than multiple put (and in terms of atomicity it's probably not much better either). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3214) When non owner updates non-tx dist cache the L1 is not updated

by William Burns (JIRA)

William Burns created ISPN-3214: ----------------------------------- Summary: When non owner updates non-tx dist cache the L1 is not updated Key: ISPN-3214 URL: https://issues.jboss.org/browse/ISPN-3214 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.2.6.Final Reporter: William Burns Assignee: Mircea Markus Non tx DIST caches only add/update the L1 on a GetKeyValueCommand. The tx DIST cache updates the L1 cache on write operations as well. This should be consistent and is a minor performance issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3028) Add tests for example configuration files

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3028?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-3028: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.3.0.CR2 Resolution: Done > Add tests for example configuration files > ----------------------------------------- > > Key: ISPN-3028 > URL: https://issues.jboss.org/browse/ISPN-3028 > Project: Infinispan > Issue Type: Task > Components: Server > Affects Versions: 5.3.0.Alpha1 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 5.3.0.CR2, 5.3.0.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013