[JBoss JIRA] (WFLY-2352) Domain controller fails to restart due to an inconsistent rollback of a redeploy
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2352:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> made a comment on [bug 1021763|https://bugzilla.redhat.com/show_bug.cgi?id=1021763]
This issue was verified using the 6.2.0.CR1 preview bits.
> Domain controller fails to restart due to an inconsistent rollback of a redeploy
> --------------------------------------------------------------------------------
>
> Key: WFLY-2352
> URL: https://issues.jboss.org/browse/WFLY-2352
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
>
> When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.
> The domain controller fails to restart with the following log messages.
> {code}
> 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.
--
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, 8 months
[JBoss JIRA] (WFLY-2352) Domain controller fails to restart due to an inconsistent rollback of a redeploy
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2352:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1021763|https://bugzilla.redhat.com/show_bug.cgi?id=1021763] from ON_QA to VERIFIED
> Domain controller fails to restart due to an inconsistent rollback of a redeploy
> --------------------------------------------------------------------------------
>
> Key: WFLY-2352
> URL: https://issues.jboss.org/browse/WFLY-2352
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha4
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
>
> When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.
> The domain controller fails to restart with the following log messages.
> {code}
> 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.
--
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, 8 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1717:
--------------------------------
Investigate idea by [~rvansa]:
As a last thought for DefaultBundler2 principle (this is the one I find most appealing): It seems to me that the thread does not do much work in the lock, so the bundle does not grab much messages. The format of batch does not specify how many messages will there be in advance, so, instead of just adding the message to list (fast), couldn't we keep the DataOutputStream and write the message to the stream?
Potential issues:
* We don't know up front whether the batch has 1 or more messages; in case of 1 message we send a single message, otherwise we send a batch. However, the wire format is different
* We'd have to associate one output stream per target destination
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
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, 8 months
[JBoss JIRA] (DROOLS-336) Property Reactivity fails on phreak
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-336:
----------------------------------
Summary: Property Reactivity fails on phreak
Key: DROOLS-336
URL: https://issues.jboss.org/browse/DROOLS-336
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
In LeftInputAdapterNode a modifyByPass happens, for a sink that has not been reached before. So it thinks it's new, and thus propagates as an insert
The real bug comes in doInsertObject method. It creates a child LT here, even though once it enters doInsertSegmentMemory the mask intersect fails. This leaves a child LT, that is not propagated. Next time update is called, as the LT is there it thinks it's a modify and propagates as a modify - but it never reached the beta node or the LeftMemory, and thus the memory corruption.
--
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, 8 months