July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1952) Use RESTEasy's HTTP frontend for the REST server

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1952?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1952: ------------------------------------- [~NadirX] is this still actual now that we have jboss serveres? > Use RESTEasy's HTTP frontend for the REST server > ------------------------------------------------ > > Key: ISPN-1952 > URL: https://issues.jboss.org/browse/ISPN-1952 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Final > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Using RESTEasy's HTTP frontend would allow the following: > - allow starting of a containerless REST Server using the startServer.sh script in the distibution > - drop the need for JBossWeb in JDG > - Give us some noticeable performance improvements -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1208) Use Hibernate Validator to validate entries stored in Infinispan

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1208?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1208: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Use Hibernate Validator to validate entries stored in Infinispan > ---------------------------------------------------------------- > > Key: ISPN-1208 > URL: https://issues.jboss.org/browse/ISPN-1208 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.0.0.FINAL > Reporter: Manik Surtani > Assignee: Manik Surtani > > Should be very trivial to implement as an additional interceptor, where values can be annotated with Hibernate Validator and the interceptor can validate the entries passed in. > Should be optional, and packaged as a separate module so that we don't pull in additional dependencies into core. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2154) Use JGroups' anycast when sending messages to multiple target

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2154?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2154: -------------------------------- Priority: Minor (was: Major) > Use JGroups' anycast when sending messages to multiple target > ------------------------------------------------------------- > > Key: ISPN-2154 > URL: https://issues.jboss.org/browse/ISPN-2154 > Project: Infinispan > Issue Type: Task > Components: RPC > Affects Versions: 5.2.0.ALPHA1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 6.0.0.Final > > > We currently emulate anycasts in CommandAwareRpcDispatcher by sending the message to each target sequentially and then waiting for all the responses in parallel. > This doesn't work very well with JGroups' RSVP protocol: if the RSVP flag is set, the send operation will block until we have received an ACK from the target, making the operation take much longer than it should. > We only use RSVP for state transfer-related commands, so this is not critical. But it should be slightly more efficient for normal commands, as well. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2154) Use JGroups' anycast when sending messages to multiple target

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2154?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2154: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Use JGroups' anycast when sending messages to multiple target > ------------------------------------------------------------- > > Key: ISPN-2154 > URL: https://issues.jboss.org/browse/ISPN-2154 > Project: Infinispan > Issue Type: Task > Components: RPC > Affects Versions: 5.2.0.ALPHA1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > > We currently emulate anycasts in CommandAwareRpcDispatcher by sending the message to each target sequentially and then waiting for all the responses in parallel. > This doesn't work very well with JGroups' RSVP protocol: if the RSVP flag is set, the send operation will block until we have received an ACK from the target, making the operation take much longer than it should. > We only use RSVP for state transfer-related commands, so this is not critical. But it should be slightly more efficient for normal commands, as well. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2154) Use JGroups' anycast when sending messages to multiple target

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2154?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2154: ------------------------------------- reducing priority as RSVP responses are only sent (rarely) during rebalances. > Use JGroups' anycast when sending messages to multiple target > ------------------------------------------------------------- > > Key: ISPN-2154 > URL: https://issues.jboss.org/browse/ISPN-2154 > Project: Infinispan > Issue Type: Task > Components: RPC > Affects Versions: 5.2.0.ALPHA1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > > We currently emulate anycasts in CommandAwareRpcDispatcher by sending the message to each target sequentially and then waiting for all the responses in parallel. > This doesn't work very well with JGroups' RSVP protocol: if the RSVP flag is set, the send operation will block until we have received an ACK from the target, making the operation take much longer than it should. > We only use RSVP for state transfer-related commands, so this is not critical. But it should be slightly more efficient for normal commands, as well. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2394) Use DataRehashedEvent to signal end of state transfer

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2394?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2394: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Use DataRehashedEvent to signal end of state transfer > ----------------------------------------------------- > > Key: ISPN-2394 > URL: https://issues.jboss.org/browse/ISPN-2394 > Project: Infinispan > Issue Type: Task > Components: State transfer > Affects Versions: 5.2.0.ALPHA1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > Since NBST was introduced the actual completion of state transfer happens later than the TopologyChangedEvent. In unit tests there is currently no simple way to find out when this actually happens so we resorted to some ugly polling (see TestingUtil.waitForRehashToComplete()). Also some other core components could benefit from such an event (eg. StaleTransactionCleanupService, see ISPN-2383). > The event should contain the CacheTopology that is being confirmed as stable. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2307) Upgrade the x-site tests so that they can be run from default profile

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2307?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2307. --------------------------------- Resolution: Done xsite test suite can now be run with -Ptest-xsite > Upgrade the x-site tests so that they can be run from default profile > ------------------------------------------------------------------------ > > Key: ISPN-2307 > URL: https://issues.jboss.org/browse/ISPN-2307 > Project: Infinispan > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 5.2.0.Alpha4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > Due to the complex setup(3 parallel clusters), the xsite tests can only be run in sequence (./bin/xsitetestrunner.sh). > It is possible to upgrade the test suite to run them in parallel together with the rest of the tests by using the SHARED_LOOPBACK protocol in jgroups. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2307) Upgrade the x-site tests so that they can be run from default profile

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2307?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2307: -------------------------------- Fix Version/s: 5.3.0.Final (was: 6.0.0.Final) > Upgrade the x-site tests so that they can be run from default profile > ------------------------------------------------------------------------ > > Key: ISPN-2307 > URL: https://issues.jboss.org/browse/ISPN-2307 > Project: Infinispan > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 5.2.0.Alpha4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.3.0.Final > > > Due to the complex setup(3 parallel clusters), the xsite tests can only be run in sequence (./bin/xsitetestrunner.sh). > It is possible to upgrade the test suite to run them in parallel together with the rest of the tests by using the SHARED_LOOPBACK protocol in jgroups. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1865) Update indexes only when needed

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1865?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1865: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Update indexes only when needed > ------------------------------- > > Key: ISPN-1865 > URL: https://issues.jboss.org/browse/ISPN-1865 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Reporter: Mathieu Lachance > Assignee: Sanne Grinovero > > // put in cache a value with 2 field, one indexed and one not indexed. > Value value = new Value(); > value.setNonIndexedFieldValue(123); > value.setIndexedFieldValue(456); > cache.put("key", value); > > // later... > // get back value from cache and update the not indexed field > Value value = cache.get("key"); > value.setNonIndexedFieldValue(789); > cache.put("key", value); > The second put operation will trigger index to update even tough it hasn't changed. > Sanne suggested : > " Thinking about it, there might be some situations in which we can detect it, for example if the put is going to carry a valid return value then we could compare values in string form.. nice, please open an improvement request on JIRA!" > See https://community.jboss.org/thread/195303 for complete reference -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2391) Throw consistent IllegalStateException(s) for ReplicableCommand#setParameters(int commandId, Object[] parameters)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2391?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2391: -------------------------------- Priority: Minor (was: Major) > Throw consistent IllegalStateException(s) for ReplicableCommand#setParameters(int commandId, Object[] parameters) > ----------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2391 > URL: https://issues.jboss.org/browse/ISPN-2391 > Project: Infinispan > Issue Type: Task > Components: RPC > Affects Versions: 5.2.0.Beta1 > Reporter: Vladimir Blagojevic > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > During review of https://github.com/infinispan/infinispan/pull/1369 Manik observed inconsistency in wording of IllegalStateException thrown from ReplicableCommand#setParameters(int commandId, Object[] parameters). However, upon further review it was noted that all implementations of ReplicableCommand#setParameters(int commandId, Object[] parameters) are inconsistent potentially confusing sys admins and support engineers. We should create a single consistent messages for all implementations of ReplicableCommand#setParameters(int commandId, Object[] parameters). -- 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

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013