July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3175) Upgrade the java hotrod client to support remote querying

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3175?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3175: -------------------------------- Assignee: Adrian Nistor (was: Galder Zamarreño) > Upgrade the java hotrod client to support remote querying > --------------------------------------------------------- > > Key: ISPN-3175 > URL: https://issues.jboss.org/browse/ISPN-3175 > Project: Infinispan > Issue Type: Sub-task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Priority: Blocker > Labels: jdg62 > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > Once we'll have ISPN-3169(define query fluent API), ISPN-3173(add a new query operation over hotrod) and ISPN-3174(String-based query language) in place, this is about connecting the dots: invoke the remote query on the server and present the result to the user. > h3.On the client side > As described in ISPN-3173, the query is sent as a byte[] to the server: the payload. > The request payload is query specific (not defined in the HR protocol) and at this stage has the following format: [Q_TYPE] [QUERY_ST] [FIRST_INDEX] [PAGE_SIZE]. This format accommodates the remote query requirements as defined in ISPN-3169. > - Q_TYPE (protobuf's byte) and query identifier, 1 for JPAQL (this is the query type we'll support). In future we'll add different query types as well. > - QUERY_STRING (protobuf's string)- JPAQL string generated by the fluent API (ISPN-3169). Parameters are encoded in this string (vs being sent separately) > - FIRST_INDEX + PAGE_SIZE (protobuf's int)- used for paginating/iterating over the result set. > HR response: [HR_SUCESS_FLAG] [payload] > PAYLOAD = [NUM_EL] [PROJ_SIZE] [ELEMENTS] > - even though at this stage we don't support projections (see ISPN-3169) PROJ_SIZE is added for future compatibility when projection will be supported. > Note that the payload for both request and response should be marshalled with protobuf as this information is read/written over multiple clients. > h3.On the server side > - the server module reads the query operation and the payload (byte[]) > - invokes QueryFacade.query(byte[]) : byte[] > - QueryFacade is an interface defined in the server modules > - has an implementation in the remote-query module (new modules) > - the reason for adding this module: RemoteQueryImpl cannot be in the server modules (ASL) as it has a dependency on the query module (LGPL) which would "contaminate" the server module. Another option would be to merge it in the query module itself, but doesn't feel like a natural fit as its responsibility is serializing data (protobuf). OTOH if it is small we can merge it there so that we don't add a new module to the system? > > For an overview on the remote querying see https://community.jboss.org/wiki/QueryingDesignInInfinispan -- 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-3170) create a Metadata store

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3170?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3170: -------------------------------- Priority: Blocker (was: Major) > create a Metadata store > ----------------------- > > Key: ISPN-3170 > URL: https://issues.jboss.org/browse/ISPN-3170 > Project: Infinispan > Issue Type: Sub-task > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Blocker > Labels: jdg62 > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > See #3: https://community.jboss.org/wiki/QueryingDesignInInfinispan -- 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-3170) create a Metadata store

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3170?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3170: -------------------------------- Labels: (was: jdg62) > create a Metadata store > ----------------------- > > Key: ISPN-3170 > URL: https://issues.jboss.org/browse/ISPN-3170 > Project: Infinispan > Issue Type: Sub-task > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Blocker > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > See #3: https://community.jboss.org/wiki/QueryingDesignInInfinispan -- 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-3172) Define and manage indexes and schemas via JMX

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3172?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3172: -------------------------------- Labels: (was: jdg62) > Define and manage indexes and schemas via JMX > --------------------------------------------- > > Key: ISPN-3172 > URL: https://issues.jboss.org/browse/ISPN-3172 > Project: Infinispan > Issue Type: Sub-task > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Blocker > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > - ability to upload/attach a .proto file > - ability to edit indexing metadata, which maps to Hibernate Search programmatic metadata API > - store schema and metadata info in Metadata Store > For an overview on the remote query design refer to: https://community.jboss.org/wiki/QueryingDesignInInfinispan -- 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-3281) Deadlock in non-transactional caches during rebalance

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3281?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3281: -------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > Deadlock in non-transactional caches during rebalance > ----------------------------------------------------- > > Key: ISPN-3281 > URL: https://issues.jboss.org/browse/ISPN-3281 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > Say we have a cache with node A and node B joins. The cache topology id is 1, primary_owner(k) = A in the current CH and primary_owner(k) = B in the pending CH. > 1. Node A starts a put(k, v) command during the rebalance. It thinks it's the primary owner, so it acquires the lock locally and it forwards the command to B. > 2. B installs topology 2, primary_owner(k) = B in the current CH, and there is no pending CH. > 3. B receives the put(k, v) command from A. It thinks it's the primary owner, so it acquires the lock locally and it forwards the command to A. > 4. A receives the put(k, v) command from B. Again it thinks it's the primary owner and tries to acquire the lock locally, but it times out because the lock is held by another thread (from step 1). > I think it may be enough to update the topology id in the put(k, v) command on node B, before forwarding it back to A. That way, the command will block on node A until topology 2 is installed, and it won't try to lock the key again. -- 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-2082) JdbcStringBasedCacheStore: ORA-24816 when storing BLOB values > 4000 bytes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2082?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2082: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > JdbcStringBasedCacheStore: ORA-24816 when storing BLOB values > 4000 bytes > -------------------------------------------------------------------------- > > Key: ISPN-2082 > URL: https://issues.jboss.org/browse/ISPN-2082 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.1.5.FINAL > Environment: OS X 10.7.4, JDK 1.7.0u4 > Reporter: Ryan Scharer > Assignee: Tristan Tarrant > > I've configured a JdbcStringBasedCacheStore with a VARCHAR(4000) key column and a BLOB value column. If I try to store a BLOB value of less than 4000 bytes, everything works fine. If the value is greater, the cache store fails with ORA-24816. This occurs because the BLOB column is not the last one in the PreparedStatement SQL as the Oracle driver requires. My current, sad workaround is to clone the JdbcStringBasedCacheStore implementation and write my own insert/update SQL in storeLockSafe(). This works fine, but obviously isn't ideal from an upgrade point of view. Simply overriding storeLockSafe() isn't an option due to all the private fields. -- 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-3119) Cleanup the scripts we ship with the distribution

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3119?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3119: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.Alpha1) > Cleanup the scripts we ship with the distribution > -------------------------------------------------- > > Key: ISPN-3119 > URL: https://issues.jboss.org/browse/ISPN-3119 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > Make sure that all the scripts we ship as part of the distribution are correct. Also update the [release process| https://docspace.corp.redhat.com/docs/DOC-28594] with exact stept to test the scripts we ship, e.g. > {quote} > 1. memcached server > $ ./startServer.sh -r memcached > # from a different console test the client > $ ./memcache.py > - ./bin/startServer.sh -r memcached > 2. Pi approximation demo. Open 3 consoles on the same machine > $ ./runPiApproximationDemo.sh > $ ./runPiApproximationDemo.sh > $ ./runPiApproximationDemo.sh -t master > {quote} > -- 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-1833) Add EmbeddedCacheManager.getGlobalComponentRegistry

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1833?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1833: -------------------------------- Assignee: Galder Zamarreño (was: Manik Surtani) > Add EmbeddedCacheManager.getGlobalComponentRegistry > --------------------------------------------------- > > Key: ISPN-1833 > URL: https://issues.jboss.org/browse/ISPN-1833 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 6.0.0.Final > > > You should be able to retrieve the global component registry out of the EmbeddedCacheManager. > Rather that having to do: > cache.getAdvancedCache().getComponentRegistry().getGlobalComponentRegistry() -- 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-1833) Add EmbeddedCacheManager.getGlobalComponentRegistry

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1833?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1833: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Add EmbeddedCacheManager.getGlobalComponentRegistry > --------------------------------------------------- > > Key: ISPN-1833 > URL: https://issues.jboss.org/browse/ISPN-1833 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > > You should be able to retrieve the global component registry out of the EmbeddedCacheManager. > Rather that having to do: > cache.getAdvancedCache().getComponentRegistry().getGlobalComponentRegistry() -- 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-1986) Make putForExternalRead return a boolean instead of void

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-1986?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-1986: ------------------------------------ putForExternalRead also uses the FORCE_ASYNCHRONOUS flag, so it's impossible to tell whether the entry was actually written to the key owners in a distributed cache (or to all the owners, in a replicated cache). If we added a return value, it would only be relevant in local or invalidation caches. > Make putForExternalRead return a boolean instead of void > -------------------------------------------------------- > > Key: ISPN-1986 > URL: https://issues.jboss.org/browse/ISPN-1986 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > Related to ISPN-1983 and https://hibernate.onjira.com/browse/HHH-7256, I'd like to change the API of putForExternalRead() to return a boolean instead of void. > The reason for doing this is to be able to find out if the PFER did actually end up storing something or not. -- 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