[JBoss JIRA] (ISPN-2580) Do not request segments from all nodes at once
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2580?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2580 started by Adrian Nistor.
> Do not request segments from all nodes at once
> ----------------------------------------------
>
> Key: ISPN-2580
> URL: https://issues.jboss.org/browse/ISPN-2580
> Project: Infinispan
> Issue Type: Enhancement
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.0.CR1
>
>
> When a new node joins large cluster filled with data, it gets the new CH and REBALANCE_START command, and requests data from all nodes at once (or almost all with even distribution of segments). It may be not able to handle this amount of transfers in parallel even at the JGroups level - this results in data sent to the node and discarded at the receiver, sent again and again. With a heavy congestion the node just buffers fragments of a message from one sender and never passes this up.
> The number of StateRequestCommands(START_STATE_TRANSFER) should be limited so that the node is not congested.
--
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, 12 months
[JBoss JIRA] (ISPN-2560) Distribution ZIP file polluted
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2560?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2560:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1546
> Distribution ZIP file polluted
> ------------------------------
>
> Key: ISPN-2560
> URL: https://issues.jboss.org/browse/ISPN-2560
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 5.2.0.Beta4
> Reporter: Manik Surtani
> Assignee: Tristan Tarrant
> Priority: Critical
> Fix For: 5.2.0.CR1, 5.2.0.Final
>
>
> There appear to be a lot of files packaged up and archived in various (incorrect and superfluous) places in the ZIP archives.
> 1. Looking at 5.2.0.Beta4-all.zip, I see:
> {code}
> Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf infinispan-core.jar | grep "\.sh"
> functions.sh
> importConfig.sh
> Multiverse:infinispan-5.2.0.Beta4-all manik $
> {code}
> Why are these shell scripts in the JAR file?
> 2. Also, I see similar things in other JAR files:
> {code}
> Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/demos/ec2/infinispan-ec2-demo.jar | grep "\.sh"
> runEC2Demo-all.sh
> runEC2Demo-influenza.sh
> runEC2Demo-nucleotide.sh
> runEC2Demo-protein.sh
> runEC2Demo-query.sh
> runEC2Demo-reader.sh
> Multiverse:infinispan-5.2.0.Beta4-all manik $
> {code}
> {code}
> Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/cli-client/infinispan-cli-client.jar | grep "\.sh"
> ispn-cli.sh
> Multiverse:infinispan-5.2.0.Beta4-all manik $
> {code}
> 3. I see these in {{/etc/}} which, if I now put {{/etc/}} in my classpath, causes things to break in spectacular ways due to the service loaded picking up incorrect metadata.
> {code}
> Multiverse:infinispan-5.2.0.Beta4-all manik $ ls etc/META-INF/services/
> org.infinispan.cli.commands.Command
> org.infinispan.cli.connection.Connector
> org.infinispan.commands.module.ModuleCommandExtensions
> org.infinispan.configuration.parsing.ConfigurationParser
> org.infinispan.distexec.mapreduce.spi.MapReduceTaskLifecycle
> org.infinispan.distexec.spi.DistributedTaskLifecycle
> org.infinispan.factories.components.ModuleMetadataFileFinder
> org.infinispan.lifecycle.ModuleLifecycle
> Multiverse:infinispan-5.2.0.Beta4-all manik $
> {code}
> 4. Why do we package {{etc/infinispan-query-component-metadata.dat}}? That should be a part of infinispan-query.jar, and not in etc.
> 5. What is in {{/etc/help}}? Looks like resource files for the CLI, which should really be in one of the CLI jars.
> Marking this as critical, since this is messy and confusing for users, and can cause breakage when running some demos and makes things very confusing to debug.
--
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, 12 months
[JBoss JIRA] (ISPN-2675) Need way to use custom create table syntax
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2675:
----------------------------------
Summary: Need way to use custom create table syntax
Key: ISPN-2675
URL: https://issues.jboss.org/browse/ISPN-2675
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Affects Versions: 5.2.0.Beta6
Reporter: Thomas Fromm
Assignee: Mircea Markus
Fix For: 5.2.0.Final
Currently with oracle and LOB as column type for cache value the LOB data are tried to store inline. This is expensive and a major performance issue (for me).
Details to this: http://www.idevelopment.info/data/Oracle/DBA_tips/LOBs/LOBS_2.shtml
So I need for the 5.2 a way to provide custom create table syntax :-|
Maybe a workaround could that I execute ALTER TABLE statement after cache startup, but then I need to check table attributes first if alter table statement is nessessary. Provide own create table statement is much easier.
--
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, 12 months