[JBoss JIRA] (WFLY-5752) Can't rename the "ejb" cache container
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5752?page=com.atlassian.jira.plugin.... ]
Ladislav Thon updated WFLY-5752:
--------------------------------
Affects Version/s: 10.0.0.CR5
> Can't rename the "ejb" cache container
> --------------------------------------
>
> Key: WFLY-5752
> URL: https://issues.jboss.org/browse/WFLY-5752
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR5
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Priority: Blocker
> Attachments: tinyRemoteEjb-server-ee7.jar
>
>
> When I rename the {{ejb}} cache container, deploying a simple app that contains an EJB ends with a horrible error message. This is a blocker, because renaming a cache container is required for a 2clusters scenario (standalone client invoking a remote EJB in cluster A, that EJB in turns invokes a remote EJB in cluster B, and forwards the response to the original client).
> More details:
> 1. {{unzip jboss-eap-7.0.0.ER2.zip}} # though ER1 is affected as well
> 2. {{cp tinyRemoteEjb-server-ee7.jar jboss-eap-7.0/standalone/deployments/}} # the JAR is attached
> 3. change the {{jboss-eap-7.0/standalone/configuration/standalone-full-ha.xml}} file like this:
> {code}
> <!-- in the "ejb3" subsystem -->
> <passivation-store name="infinispan" cache-container="ejb2" max-size="10000"/>
> <remote cluster="ejb2" connector-ref="http-remoting-connector" thread-pool-name="default"/>
> <!-- in the "infinispan" subsystem -->
> <cache-container name="ejb2" ...>
> {code}
> 4. {{./jboss-eap-7.0/bin/standalone.sh -c standalone-full-ha.xml}}
> This leads to:
> {code}
> 14:11:22,473 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "tinyRemoteEjb-server-ee7.jar")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".WeldStartService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.CREATE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.JndiBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.START",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.VIEW.\"cz.ladicek.tinyRemoteEjb.server.MyBean\".REMOTE",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInstantiator",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInterceptorBindingsService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".deploymentCompleteService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".jndiDependencyService",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformation",
> "jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
> "jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\""
> ],
> "Services that may be the cause:" => ["jboss.clustering.registry.ejb2.client-mappings"]
> }}
> 14:11:22,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.remoting.connector.client-mappings.installer is missing [jboss.clustering.registry.ejb2.client-mappings]"]}
> {code}
> This works perfectly fine in 7.0.0.DR13, so I did a {{git bisect}} and traced the problem to this commit: https://github.com/jbossas/jboss-eap7/commit/232dff042f The error message mentions that an {{...ejb2.client-mappings}} service is missing, which is consistent with the commit message (also mentions client mappings).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-5752) Can't rename the "ejb" cache container
by Ladislav Thon (JIRA)
Ladislav Thon created WFLY-5752:
-----------------------------------
Summary: Can't rename the "ejb" cache container
Key: WFLY-5752
URL: https://issues.jboss.org/browse/WFLY-5752
Project: WildFly
Issue Type: Bug
Components: Clustering, EJB
Reporter: Ladislav Thon
Assignee: Paul Ferraro
Priority: Blocker
When I rename the {{ejb}} cache container, deploying a simple app that contains an EJB ends with a horrible error message. This is a blocker, because renaming a cache container is required for a 2clusters scenario (standalone client invoking a remote EJB in cluster A, that EJB in turns invokes a remote EJB in cluster B, and forwards the response to the original client).
More details:
1. {{unzip jboss-eap-7.0.0.ER2.zip}} # though ER1 is affected as well
2. {{cp tinyRemoteEjb-server-ee7.jar jboss-eap-7.0/standalone/deployments/}} # the JAR is attached
3. change the {{jboss-eap-7.0/standalone/configuration/standalone-full-ha.xml}} file like this:
{code}
<!-- in the "ejb3" subsystem -->
<passivation-store name="infinispan" cache-container="ejb2" max-size="10000"/>
<remote cluster="ejb2" connector-ref="http-remoting-connector" thread-pool-name="default"/>
<!-- in the "infinispan" subsystem -->
<cache-container name="ejb2" ...>
{code}
4. {{./jboss-eap-7.0/bin/standalone.sh -c standalone-full-ha.xml}}
This leads to:
{code}
14:11:22,473 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "tinyRemoteEjb-server-ee7.jar")]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
"Services that were unable to start:" => [
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".CdiValidatorFactoryService",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".WeldStartService",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.CREATE",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.JndiBindingsService",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.START",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.VIEW.\"cz.ladicek.tinyRemoteEjb.server.MyBean\".REMOTE",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInstantiator",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".component.MyBeanImpl.WeldInterceptorBindingsService",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".deploymentCompleteService",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".jndiDependencyService",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformation",
"jboss.deployment.unit.\"tinyRemoteEjb-server-ee7.jar\".moduleDeploymentRuntimeInformationStart",
"jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
"jboss.naming.context.java.app.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
"jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.MyBeanImpl",
"jboss.naming.context.java.global.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\"",
"jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.MyBeanImpl",
"jboss.naming.context.java.module.tinyRemoteEjb-server-ee7.tinyRemoteEjb-server-ee7.\"MyBeanImpl!cz.ladicek.tinyRemoteEjb.server.MyBean\""
],
"Services that may be the cause:" => ["jboss.clustering.registry.ejb2.client-mappings"]
}}
14:11:22,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "ejb3"),
("service" => "remote")
]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.ejb.remoting.connector.client-mappings.installer is missing [jboss.clustering.registry.ejb2.client-mappings]"]}
{code}
This works perfectly fine in 7.0.0.DR13, so I did a {{git bisect}} and traced the problem to this commit: https://github.com/jbossas/jboss-eap7/commit/232dff042f The error message mentions that an {{...ejb2.client-mappings}} service is missing, which is consistent with the commit message (also mentions client mappings).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-5751) Service can't be installed if the path contains a closed bracket
by Paul Wildberg (JIRA)
[ https://issues.jboss.org/browse/WFLY-5751?page=com.atlassian.jira.plugin.... ]
Paul Wildberg commented on WFLY-5751:
-------------------------------------
Maybe there are some more double quotation marks missing,
e.g. jboss-clie.bat in \wildfly-9.0.1.Final\bin\ in line 67 (set "LOGGING_CONFIG=-Dlogging.configuration=file:%JBOSS_HOME%\bin\jboss-cli-logging.properties") - the path of JBOSS_HOME\... is not in double quotation marks.
The whole line is in double quotation marks, but I'm not sure that it works.
> Service can't be installed if the path contains a closed bracket
> ----------------------------------------------------------------
>
> Key: WFLY-5751
> URL: https://issues.jboss.org/browse/WFLY-5751
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 9.0.1.Final, 9.0.2.Final, 10.0.0.CR4
> Environment: all Windows versions
> Reporter: Paul Wildberg
> Assignee: Cheng Fang
> Priority: Critical
> Labels: jboss
>
> Problem:
> If you start "service.bat install" in e.g. in C:\Program Files (x86)\wildfly-9.0.1.Final\bin\service you will get:
> Using the X86-64bit version of prunsrv
> "\wildfly-9.0.1.Final\domain\log" can not be used syntatically at this point (don't know if it is correct, I translated it from german. Original it is "kann syntaktisch an dieser Stelle nicht verarbeitet werden.")
> Cause:
> This is because of the ) in "Program Files (x86)" and this is a problem because in the service.bat in line 175 and 179 (set LOGPATH=%JBOSS_HOME%\domain\log - in version 9.0.1 and 9.0.2 - in Version 10 it may be in another line) the path is not set in double quotation marks.
> All other paths are set in double quotation marks.
> Solution:
> Set the path in double quotation marks:
> set LOGPATH="%JBOSS_HOME%\domain\log"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ELY-383) Update ServerAuthenticationContext to carry an identity from start to end
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-383?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-383:
---------------------------------
Actually, the transition from the "INITIAL Ⓐ" to "AUTHORIZED Ⓑ" states is better done as "INITIAL Ⓐ" to "AUTHORIZED Ⓐ", and from there to "AUTHORIZED Ⓑ".
> Update ServerAuthenticationContext to carry an identity from start to end
> -------------------------------------------------------------------------
>
> Key: ELY-383
> URL: https://issues.jboss.org/browse/ELY-383
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta3
>
> Attachments: Blank Flowchart - ServerAuthenticationContext.png
>
>
> The {{ServerAuthenticationContext}} should capture the identity in force for its domain when it is constructed. Any authorization attempt should always apply to the current identity - either the captured identity, or whatever the last successfully authorized identity was in the context.
> The attached state diagram should accurately summarize how authorization identity flows through. Authentication identity is only available during the "NAME ASSIGNED" state; once authorization occurs, the authentication identity is no longer useful and is disposed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (JGRP-1990) Headers: use 1 array rather than 2
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1990?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1990.
----------------------------
Resolution: Done
> Headers: use 1 array rather than 2
> ----------------------------------
>
> Key: JGRP-1990
> URL: https://issues.jboss.org/browse/JGRP-1990
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Currently, {{Headers}} uses 1 array for ids and 1 for the actual headers. Experiment whether joining them into one array makes sense, e.g.:
> {noformat}
> | id-1 | hdr-1 | id-2 | hdr-2 | ... | id-n | hdr-n |
> {noformat}
> This saves 4 bytes (compressed OOPs) for an array ref, plus the overhead of the array itself. Plus, resizing only has to be applied to 1 array.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (JGRP-1990) Headers: use 1 array rather than 2
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1990?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1990:
--------------------------------
The memory savings are nice:
{noformat}
org.jgroups.util.Headers object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 4 short[] Headers.ids N/A
16 4 Header[] Headers.hdrs N/A
20 4 (loss due to the next object alignment)
Instance size: 24 bytes (estimated, the sample instance is not available)
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
{noformat}
A message had a ref to a {{Headers}} instance, which had refs to an {{id}} (carrying the prot-ids) and a {{headers}} array (carrying the actual headers). A {{Headers}} instances takes roughly 24 bytes of memory as shown above. Half of that is the cost of the _object header_ (12 bytes)!
The new message has a ref to a {{Header[]}} array, in which all headers are stored. The {{Header}} abstract superclass now also carries a short which adds 2 bytes to each header.
The advantages of this new approach, which stores headers directly in an array of {{Message}} are:
* Less memory need: the overall cost of maintaining headers (without the cost of the actual headers) is now ~ 24 bytes - 2 bytes = *22 bytes lower* (per message) !
* If the headers array needs to be grown, we only have to grow 1 rather than 2 arrays
> Headers: use 1 array rather than 2
> ----------------------------------
>
> Key: JGRP-1990
> URL: https://issues.jboss.org/browse/JGRP-1990
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> Currently, {{Headers}} uses 1 array for ids and 1 for the actual headers. Experiment whether joining them into one array makes sense, e.g.:
> {noformat}
> | id-1 | hdr-1 | id-2 | hdr-2 | ... | id-n | hdr-n |
> {noformat}
> This saves 4 bytes (compressed OOPs) for an array ref, plus the overhead of the array itself. Plus, resizing only has to be applied to 1 array.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (DROOLS-891) Missing alpha node removal when the only rule using it is removed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-891?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-891:
------------------------------------------------
Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from MODIFIED to ON_QA
> Missing alpha node removal when the only rule using it is removed
> -----------------------------------------------------------------
>
> Key: DROOLS-891
> URL: https://issues.jboss.org/browse/DROOLS-891
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR2
>
>
> When an alpha node has more than one sink and it is used by only one rule doesn't get removed when the rule itself is removed. The following test case demonstrates the problem.
> {code}
> @Test
> public void testRemoveHasSameConElement() {
> String packageName = "test";
> String rule1 = "package " + packageName + ";" +
> "import java.util.Map; \n" +
> "rule 'rule1' \n" +
> "when \n" +
> " Map(this['type'] == 'Goods' && this['brand'] == 'a') \n" +
> " Map(this['type'] == 'Goods' && this['category'] == 'b') \n" +
> "then \n" +
> "System.out.println('test rule 1'); \n"+
> "end";
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add( ResourceFactory.newByteArrayResource( rule1.getBytes() ), ResourceType.DRL );
> if ( kbuilder.hasErrors() ) {
> fail( kbuilder.getErrors().toString() );
> }
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );
> kbase.removeKnowledgePackage(packageName);
> StatelessKnowledgeSession session = kbase.newStatelessKnowledgeSession();
> session.execute(new HashMap());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (DROOLS-951) Removing 2 or more rules does not retract justified objects
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-951?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-951:
------------------------------------------------
Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from MODIFIED to ON_QA
> Removing 2 or more rules does not retract justified objects
> -----------------------------------------------------------
>
> Key: DROOLS-951
> URL: https://issues.jboss.org/browse/DROOLS-951
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Zvonimir Bošnjak
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> When removing rules from knowledge which have logically inserted (justified) objects, only one object (from first removed rule) will be retracted.
> In example from AddRemoveRule#184: as it removes the first rule, it re-initializes all other path memories and, in particular, marks them as unlinked (AbstractTerminalNode#204)
> Later, when it tries to flush the deletions (AddRemoveRule#280), the unlinked status prevents the propagation from taking place.
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months