[JBoss JIRA] (JGRP-1649) RELAY2: everyone can be a site master
by Bela Ban (JIRA)
Bela Ban created JGRP-1649:
------------------------------
Summary: RELAY2: everyone can be a site master
Key: JGRP-1649
URL: https://issues.jboss.org/browse/JGRP-1649
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.4
The site master can become a bottleneck if we have a lot of traffic between sites. Also, forwarding messages to a local site master and the site master of the target site forwarding messages to the final destination generates additional traffic.
Therefore, allow every member to become a site master:
* Every member joins the local cluster (site) *and* the global cluster
** Everyone (as a site master) maintains a routing table that consists of target sites ("sfo") and a list of site masters
* When a message is received whose destination is SiteMaster"sfo"), we pick a random member of the list for "sfo" and relay the message to it
* The target site master then receives and possibly forwards the message to the final destination (if it isn't the final dest)
Not sure yet if this will be a new protocol (RELAY3) or whether RELAY2 will be enhanced.
Also, investigate whether it makes sense to make only a *subset* of the site nodes site masters. This would still require local forwarding from non site masters.
--
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
13 years
[JBoss JIRA] (WFLY-917) jboss-ejb3.xml faults fail silently and result in a hanging thread
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-917?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated WFLY-917:
--------------------------------------
Forum Reference: https://community.jboss.org/message/825700#825700
> jboss-ejb3.xml faults fail silently and result in a hanging thread
> ------------------------------------------------------------------
>
> Key: WFLY-917
> URL: https://issues.jboss.org/browse/WFLY-917
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Environment: MacOS X 10.8.2
> java version "1.6.0_35"
> Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
> Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
> Reporter: Stephen Coy
> Assignee: Eduardo Martins
> Attachments: migration-demo.tar.gz
>
>
> The attached maven application project has a subtle typo in a JNDI name in the jboss-ejb3.xml file.
> The deployment process results in a hanging thread shown below. There are no diagnostic log messages at all to indicate what the problem could be.
> A second consequence of this hung thread is that the server process can only be terminated with a "kill -9 <pid>".
> Note that it is deliberately a JEE5 compatible application.
> "management-handler-thread - 4" prio=5 tid=7f843c0bf000 nid=0x10a866000 in Object.wait() [10a864000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
> - locked <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
> at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:442)
> at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:147)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:261)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentHandlerUtil$1.execute(DeploymentHandlerUtil.java:123)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentDeployHandler.execute(DeploymentDeployHandler.java:75)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:168)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:85)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:473)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:126)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Locked ownable synchronizers:
> - <7d42a5150> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> - <7d4f3b598> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
--
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
13 years
[JBoss JIRA] (WFLY-1242) Use JBoss Logging for resource adapter LogWriter
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/WFLY-1242?page=com.atlassian.jira.plugin.... ]
Osamu Nagano edited comment on WFLY-1242 at 7/3/13 2:06 AM:
------------------------------------------------------------
Besides the logging system integration, the current stdout log writer is not working properly. It actually outputs nothing. The PrintWriter object should be auto flushed like {{new PrintWriter(System.out, true)}} as a short-term solution.
{code:title=https://github.com/jbossas/jboss-as/blob/master/connector/src/main/java/org/jboss/as/connector/services/resourceadapters/deployment/AbstractResourceAdapterDeploymentService.java#L387}
@Override
protected PrintWriter getLogPrintWriter() {
return new PrintWriter(System.out);
}
{code}
WFLY-1630 is created for this specific fix.
was (Author: osamu.nagano):
Besides the logging system integration, the current stdout log writer is not working properly. It actually outputs nothing. The PrintWriter object should be auto flushed like {{new PrintWriter(System.out, true)}} as a short-term solution.
{code:title=https://github.com/jbossas/jboss-as/blob/master/connector/src/main/java/org/jboss/as/connector/services/resourceadapters/deployment/AbstractResourceAdapterDeploymentService.java#L387}
@Override
protected PrintWriter getLogPrintWriter() {
return new PrintWriter(System.out);
}
{code}
> Use JBoss Logging for resource adapter LogWriter
> ------------------------------------------------
>
> Key: WFLY-1242
> URL: https://issues.jboss.org/browse/WFLY-1242
> Project: WildFly
> Issue Type: Task
> Components: JCA
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
>
> Have each resource adapter deployment use JBoss Logging for its LogWriter implementation.
> Logging category should include the resource adapter name (eis.rar), and activation id.
--
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
13 years
[JBoss JIRA] (WFLY-1630) LogWriter of ManagedConnectionFactory outputs nothing to stdout
by Osamu Nagano (JIRA)
Osamu Nagano created WFLY-1630:
----------------------------------
Summary: LogWriter of ManagedConnectionFactory outputs nothing to stdout
Key: WFLY-1630
URL: https://issues.jboss.org/browse/WFLY-1630
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Osamu Nagano
Assignee: Jesper Pedersen
ManagedConnectionFactory#setLogWriter() passes a PrintWriter object for logging use of the connector. It is supposed to output log messages to stdout but none of the messages are observed.
In WFLY-1242 an integration with JBoss Logging is planned but this specific fix is needed until the integration.
--
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
13 years
[JBoss JIRA] (WFLY-1629) init.d Script for Debian based distros
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFLY-1629?page=com.atlassian.jira.plugin.... ]
Jorge Solorzano updated WFLY-1629:
----------------------------------
Summary: init.d Script for Debian based distros (was: Init Script debian)
Description:
init.d scripts provided by WildFly are designed for RedHat/Fedora, and it should provide a script that works well in Debian/Ubuntu based distributions.
I could provide a LSB-compliant init script with all the features required for a complete startup script.
was:init.d scripts provided by WildFly are designed for RedHat/Fedora, and it should provide a script that works well in Debian/Ubuntu based distributions.
> init.d Script for Debian based distros
> --------------------------------------
>
> Key: WFLY-1629
> URL: https://issues.jboss.org/browse/WFLY-1629
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2
> Environment: Debian/Ubuntu based
> Reporter: Jorge Solorzano
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: Debian,, Ubuntu, init.d
>
> init.d scripts provided by WildFly are designed for RedHat/Fedora, and it should provide a script that works well in Debian/Ubuntu based distributions.
> I could provide a LSB-compliant init script with all the features required for a complete startup script.
--
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
13 years
[JBoss JIRA] (WFLY-1629) Init Script debian
by Jorge Solorzano (JIRA)
Jorge Solorzano created WFLY-1629:
-------------------------------------
Summary: Init Script debian
Key: WFLY-1629
URL: https://issues.jboss.org/browse/WFLY-1629
Project: WildFly
Issue Type: Enhancement
Components: Scripts
Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha1
Environment: Debian/Ubuntu based
Reporter: Jorge Solorzano
Assignee: Brian Stansberry
Priority: Minor
init.d scripts provided by WildFly are designed for RedHat/Fedora, and it should provide a script that works well in Debian/Ubuntu based distributions.
--
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
13 years