November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2236: --------------------------- Fix Version/s: 4.0.9 > UNICAST max_xmit_req_size doesn't work > -------------------------------------- > > Key: JGRP-2236 > URL: https://issues.jboss.org/browse/JGRP-2236 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > Fix For: 4.0.9 > > > UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size. > But the check is implemented incorrectly, so it is not effective. > JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ] Dennis Reed updated JGRP-2236: ------------------------------ > UNICAST max_xmit_req_size doesn't work > -------------------------------------- > > Key: JGRP-2236 > URL: https://issues.jboss.org/browse/JGRP-2236 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > > UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size. > But the check is implemented incorrectly, so it is not effective. > JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/JGRP-2236?page=com.atlassian.jira.plugin.... ] Dennis Reed commented on JGRP-2236: ----------------------------------- UNICAST3.init sets max_xmit_req_size based on the maximum number of messages that will fit in a SeqnoList that will serialize to the maximum bundle size. *BUT* org.jgroups.util.Table.Missing uses it as the number of bits turned on in the SeqnoList instead of the actual size of the SeqnoList itself (which grows without bound based solely on the size of the Table). > UNICAST max_xmit_req_size doesn't work > -------------------------------------- > > Key: JGRP-2236 > URL: https://issues.jboss.org/browse/JGRP-2236 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Dennis Reed > Assignee: Bela Ban > > UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size. > But the check is implemented incorrectly, so it is not effective. > JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2236) UNICAST max_xmit_req_size doesn't work

by Dennis Reed (JIRA)

Dennis Reed created JGRP-2236: --------------------------------- Summary: UNICAST max_xmit_req_size doesn't work Key: JGRP-2236 URL: https://issues.jboss.org/browse/JGRP-2236 Project: JGroups Issue Type: Bug Affects Versions: 4.0.1 Reporter: Dennis Reed Assignee: Bela Ban UNICAST3 sets max_xmit_req_size to avoid requesting too many messages to fit into the maximum message size. But the check is implemented incorrectly, so it is not effective. JGRP000029: node1: failed sending message to node2 (120314 bytes): java.io.IOException: Message too long, headers: UNICAST3: XMIT_REQ, seqno=0, TP: [cluster_name=cluster] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9562) Issue creating replicated cache in standalone-ha

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-9562?page=com.atlassian.jira.plugin.... ] Steven Hawkins commented on WFLY-9562: -------------------------------------- > Perform all related operations for creating a cache-container or cache within a batch That seems to work. Thank you. > Additionally, the CLI script at the link in the jira description relies on deprecated paths for the cache components. While this still works as of WF 11, this script should be updated as support for legacy paths will be removed in a future release. I'll make that update as well. Is there a deprecation message that is expected somewhere? I did see one related to the batching attribute, but nothing on the component paths. > Issue creating replicated cache in standalone-ha > ------------------------------------------------ > > Key: WFLY-9562 > URL: https://issues.jboss.org/browse/WFLY-9562 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Steven Hawkins > Assignee: Paul Ferraro > > Attempting to install teiid into standalone-ha via a cli scripts fails with: > {code} > 09:12:37,399 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache-configuration.teiid-cache.resultset-repl: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-configuration.teiid-cache.resultset-repl: Failed to start service > ... > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000343: Must have a transport set in the global configuration in order to define a clustered cache > at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:229) > at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:240) > at org.infinispan.configuration.ConfigurationManager.putConfiguration(ConfigurationManager.java:80) > at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:390) > at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:353) > at org.jboss.as.clustering.infinispan.DefaultCacheContainer.defineConfiguration(DefaultCacheContainer.java:73) > at org.wildfly.clustering.infinispan.spi.service.ConfigurationBuilder.start(ConfigurationBuilder.java:88) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > {code} > This worked with prior WildFly releases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9562) Issue creating replicated cache in standalone-ha

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9562?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-9562. ------------------------------ Resolution: Rejected It has always been the expectation that the operations for creating a cache-container or cache should execute within a batch. While the script in the jira description might not have failed against a previous release, it would not have yielded the expected results without a reload of the server. If this CLI script is run against a running server, you *must* either: * Perform all related operations for creating a cache-container or cache within a batch e.g. {code} batch /subsystem=infinispan/cache-container=teiid-cache:add(default-cache=resultset) /subsystem=infinispan/cache-container=teiid-cache/transport=jgroups:add(lock-timeout=60000) /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset:add() /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=locking:add(isolation=READ_COMMITTED) /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=expiration:add(lifespan=7200000) /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=eviction:add(max-entries=1024, strategy=LIRS) /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=transaction:add(mode=NON_XA) run-batch batch /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl:add(mode=SYNC) /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=locking:add(isolation=READ_COMMITTED) /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=expiration:add(lifespan=7200000) /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=eviction:add(max-entries=1024, strategy=LIRS) /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=transaction:add(mode=NON_XA) run-batch batch /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan:add() /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan/component=locking:add(isolation=READ_COMMITTED) /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan/component=expiration:add(lifespan=28800) /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan/component=eviction:add(max-entries=512, strategy=LIRS) /subsystem=infinispan/cache-container=teiid-cache:write-attribute(name=default-cache, value=resultset) run-batch {code} * Use the \{allow-resource-service-restart=true} operation flag to ensure all services created by the related parent operation are restarted e.g. {code} /subsystem=infinispan/cache-container=teiid-cache:add() /subsystem=infinispan/cache-container=teiid-cache/transport=jgroups:add(lock-timeout=60000)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl:add(mode=SYNC) /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=locking:add(isolation=READ_COMMITTED)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=expiration:add(lifespan=7200000)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=eviction:add(max-entries=1024, strategy=LIRS)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/replicated-cache=resultset-repl/component=transaction:add(mode=NON_XA)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset:add() /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=locking:add(isolation=READ_COMMITTED)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=expiration:add(lifespan=7200000)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=eviction:add(max-entries=1024, strategy=LIRS)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/local-cache=resultset/component=transaction:add(mode=NON_XA)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan:add() /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan/component=locking:add(isolation=READ_COMMITTED)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan/component=expiration:add(lifespan=28800)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache/local-cache=preparedplan/component=eviction:add(max-entries=512, strategy=LIRS)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache:write-attribute(name=default-cache, value=resultset)\{allow-resource-service-restart=true} /subsystem=infinispan/cache-container=teiid-cache:write-attribute(name=default-cache, value=resultset)\{allow-resource-service-restart=true} {code} Additionally, the CLI script at the link in the jira description relies on deprecated paths for the cache components. While this still works as of WF 11, this script should be updated as support for legacy paths will be removed in a future release. > Issue creating replicated cache in standalone-ha > ------------------------------------------------ > > Key: WFLY-9562 > URL: https://issues.jboss.org/browse/WFLY-9562 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Steven Hawkins > Assignee: Paul Ferraro > > Attempting to install teiid into standalone-ha via a cli scripts fails with: > {code} > 09:12:37,399 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache-configuration.teiid-cache.resultset-repl: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-configuration.teiid-cache.resultset-repl: Failed to start service > ... > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000343: Must have a transport set in the global configuration in order to define a clustered cache > at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:229) > at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:240) > at org.infinispan.configuration.ConfigurationManager.putConfiguration(ConfigurationManager.java:80) > at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:390) > at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:353) > at org.jboss.as.clustering.infinispan.DefaultCacheContainer.defineConfiguration(DefaultCacheContainer.java:73) > at org.wildfly.clustering.infinispan.spi.service.ConfigurationBuilder.start(ConfigurationBuilder.java:88) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > {code} > This worked with prior WildFly releases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1974) [DMN Editor] Test marshalling of Knowledge Source

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1974?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1974: ---------------------------------- Fix Version/s: (was: 7.5.0.Final) > [DMN Editor] Test marshalling of Knowledge Source > ------------------------------------------------- > > Key: DROOLS-1974 > URL: https://issues.jboss.org/browse/DROOLS-1974 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Jozef Marko > Assignee: Jozef Marko > > Test that marshalling of Knowledge Source preserves all properties specific for the Knowledge Source. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1939) [DMN Editor] Toolbar reacts on the Enter key

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1939?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1939: ---------------------------------- Fix Version/s: (was: 7.5.0.Final) > [DMN Editor] Toolbar reacts on the Enter key > -------------------------------------------- > > Key: DROOLS-1939 > URL: https://issues.jboss.org/browse/DROOLS-1939 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.1.0.Beta2 > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Trivial > Labels: reported-by-qe > Attachments: 1.png, 2.png, 3.png, 4.png > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1940) [DMN Editor] Dynamic Form "read only" not working

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1940?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1940: ---------------------------------- Fix Version/s: (was: 7.5.0.Final) > [DMN Editor] Dynamic Form "read only" not working > ------------------------------------------------- > > Key: DROOLS-1940 > URL: https://issues.jboss.org/browse/DROOLS-1940 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Pere Fernández Pérez > > I don't know whether it's related to my problems with a object hierarchy and {{@FormField}} re-use; but fields annotated {{@FieldReadOnly}} do not appear as read-only in the "Properties Panel". For example:- > {code} > @FieldDefinition(labelMode = LabelMode.OVERRIDE_I18N_KEY) > public class Id implements DMNProperty { > ... > @ReadOnly > @FieldReadOnly > public static final Boolean readOnly = true; > ... > } > public abstract class DMNModelInstrumentedBase implements DMNDefinition { > > //No @FormFields etc > > } > > public abstract class DMNElement extends DMNModelInstrumentedBase { > > @Property > @FormField > protected Id id; > .... > } > > public abstract class NamedElement extends DMNElement { > .... > } > > @FormDefinition(policy = FieldPolicy.ONLY_MARKED) > public class InformationItem extends NamedElement implements DMNPropertySet { > .... > } > {code} > The "Propeties" widget for "Id" can still be edited; although changes are not persisted (i.e. if I change the "Id" to "xyz" and then click on a different node and back to the one I changed the "Id" property is not "xyz"). I would however expected the {{TextBox}} to have been read-only and the value not editable. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1958) [DMN Editor] Import datatype from XSD

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1958?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1958: ---------------------------------- Fix Version/s: (was: 7.5.0.Final) > [DMN Editor] Import datatype from XSD > ------------------------------------- > > Key: DROOLS-1958 > URL: https://issues.jboss.org/browse/DROOLS-1958 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Jozef Marko > Assignee: Michael Anstis > Labels: reported-by-qe > > The DMN editor should allow to import data type declared in XSD. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2017