[JBoss JIRA] (ISPN-5699) Simplify entry wrapping
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5699?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5699:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.1.0.Alpha2
Resolution: Done
> Simplify entry wrapping
> -----------------------
>
> Key: ISPN-5699
> URL: https://issues.jboss.org/browse/ISPN-5699
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 8.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.0.Alpha2, 8.1.0.Final
>
>
> The entry wrapping should be more or less the same for all write commands.
> Currently we have some optimizations to skip wrapping in some cases, in the first phase we should probably keep them:
> * Non-repeatable reads don't store anything in the context if the value is null
> * Replace and remove store a null entry in the context
> * PutForExternalRead doesn't store anything in the context if the value is non-null
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5806) Add transaction support for Functional API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5806?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-5806:
----------------------------------------
After careful consideration, it was agreed that running non-transactional operations in a transactional cache could be problematic. The real solution here is to implement transaction support for Functional API.
> Add transaction support for Functional API
> ------------------------------------------
>
> Key: ISPN-5806
> URL: https://issues.jboss.org/browse/ISPN-5806
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Alpha2, 8.1.0.Final
>
>
> A local cache with batching enabled produces this:
> {code:java}
> java.lang.IllegalArgumentException: Cannot create a transactional
> context without a valid Transaction instance.
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
> at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
> (<-- experimental uncommitted code here)
> {code}
> For single operations that carry no transaction context, don't try to start a transaction and create a transactional context.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5806) Add transaction support for Functional API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5806?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5806:
-----------------------------------
Summary: Add transaction support for Functional API (was: Do not start a transaction for single operations)
> Add transaction support for Functional API
> ------------------------------------------
>
> Key: ISPN-5806
> URL: https://issues.jboss.org/browse/ISPN-5806
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Alpha2, 8.1.0.Final
>
>
> A local cache with batching enabled produces this:
> {code:java}
> java.lang.IllegalArgumentException: Cannot create a transactional
> context without a valid Transaction instance.
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
> at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
> (<-- experimental uncommitted code here)
> {code}
> For single operations that carry no transaction context, don't try to start a transaction and create a transactional context.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5357:
-----------------------------------
Description:
*UPDATE (6/10/2015)*: Hot Rod 3.0 could become a HTTP REST protocol taking advantage of existing infrastructure to deal with HTTP requests efficiently, and if it was based on HTTP 2.0, we could have binary data inside of it. Performance should be on par. Text mode could be available for debug or demos. This essentially would mean REST and Hot Rod would merge into one.
A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
was:
A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
Fix Version/s: 9.0.0.Final
> Hot Rod protocol 3.0
> --------------------
>
> Key: ISPN-5357
> URL: https://issues.jboss.org/browse/ISPN-5357
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Final
>
>
> *UPDATE (6/10/2015)*: Hot Rod 3.0 could become a HTTP REST protocol taking advantage of existing infrastructure to deal with HTTP requests efficiently, and if it was based on HTTP 2.0, we could have binary data inside of it. Performance should be on par. Text mode could be available for debug or demos. This essentially would mean REST and Hot Rod would merge into one.
> A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
> In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
> An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño reassigned ISPN-5357:
--------------------------------------
Assignee: Galder Zamarreño
> Hot Rod protocol 3.0
> --------------------
>
> Key: ISPN-5357
> URL: https://issues.jboss.org/browse/ISPN-5357
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
> In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
> An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5357:
-----------------------------------
Status: Open (was: New)
> Hot Rod protocol 3.0
> --------------------
>
> Key: ISPN-5357
> URL: https://issues.jboss.org/browse/ISPN-5357
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
> In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
> An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5825) Create Docker image for Infinispan Server
by Pedro Zapata (JIRA)
Pedro Zapata created ISPN-5825:
----------------------------------
Summary: Create Docker image for Infinispan Server
Key: ISPN-5825
URL: https://issues.jboss.org/browse/ISPN-5825
Project: Infinispan
Issue Type: Feature Request
Components: Server
Reporter: Pedro Zapata
Release a Docker image for Infinispan Server only. User can specify their own JGroups configuration file and Infinispan Cache configuration files as a startup parameter. If either configuration file is not specified, use the defaults shipped with JDG Server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5824) Migration tool for library mode configuration
by Pedro Zapata (JIRA)
Pedro Zapata created ISPN-5824:
----------------------------------
Summary: Migration tool for library mode configuration
Key: ISPN-5824
URL: https://issues.jboss.org/browse/ISPN-5824
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Reporter: Pedro Zapata
Regarding Configuration, the big changes: Library mode and Client-server mode have same configurations. Any infinispan.xml in Library will need to be changed substantially. We will need to write a migrator tool from old Library xml to Library xml. JDG Server will be able to read existing Server infinispan.xml and change it to latest version (upon any action on the Management model).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (ISPN-5824) Migration tool for configuration for both library mode and server
by Pedro Zapata (JIRA)
[ https://issues.jboss.org/browse/ISPN-5824?page=com.atlassian.jira.plugin.... ]
Pedro Zapata updated ISPN-5824:
-------------------------------
Summary: Migration tool for configuration for both library mode and server (was: Migration tool for library mode configuration)
> Migration tool for configuration for both library mode and server
> -----------------------------------------------------------------
>
> Key: ISPN-5824
> URL: https://issues.jboss.org/browse/ISPN-5824
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Pedro Zapata
> Labels: jdg7
>
> Regarding Configuration, the big changes: Library mode and Client-server mode have same configurations. Any infinispan.xml in Library will need to be changed substantially. We will need to write a migrator tool from old Library xml to Library xml. JDG Server will be able to read existing Server infinispan.xml and change it to latest version (upon any action on the Management model).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months