August 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-523) Issues with custom packaging in maven

by Paul Gier (JIRA)

Issues with custom packaging in maven ------------------------------------- Key: JBBUILD-523 URL: https://jira.jboss.org/jira/browse/JBBUILD-523 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - Maint 2009 Steve ran into some issues when using custom packaging for the jdocbook plugin. - Transitive dependency resolution does not work - Two dependencies with the same packaging but different artifact handlers cannot both be resolved, because no info about the handler is encoded into the repo - The plugin containing the custom packaging needs to programmatically register the artifact handler in addition to specifiying it in the components.xml this has to be done by: (1) retrieve the handler using @parameter expression="${component.org.apache.maven.artifact.handler.ArtifactHandler#jdocbook-style}" (2) manually register it using project.getArtifact().setArtifactHandler( artifactHandler ); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (AS7-1326) Cannot redeploy OSGi bundle that is wired to webapp

by Thomas Diesler (JIRA)

Cannot redeploy OSGi bundle that is wired to webapp --------------------------------------------------- Key: AS7-1326 URL: https://issues.jboss.org/browse/AS7-1326 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.Final Reporter: Thomas Diesler Assignee: Thomas Diesler {code} 09:12:12,719 ERROR [org.jboss.msc.service] (MSC service thread 1-1) MSC00002: Invocation of listener "org.jboss.as.osgi.deployment.BundleStartTracker$1@2789a406" failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.module.spec.service."deployment.jboss-osgi-example-jbossas-bundle"."0.0.0" is already registered at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154) at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226) at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560) at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194) at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) at org.jboss.as.osgi.service.ModuleLoaderIntegration.addModule(ModuleLoaderIntegration.java:122) at org.jboss.osgi.framework.internal.ModuleManagerPlugin.createHostModule(ModuleManagerPlugin.java:340) at org.jboss.osgi.framework.internal.ModuleManagerPlugin.addModule(ModuleManagerPlugin.java:225) at org.jboss.osgi.framework.internal.ResolverPlugin.addModules(ResolverPlugin.java:248) at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:226) at org.jboss.osgi.framework.internal.ResolverPlugin.resolve(ResolverPlugin.java:161) at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551) at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:210) at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494) at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:146) at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:121) {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
9
0 / 0

[JBoss JIRA] Created: (AS7-735) Failed OSGi deployments still show as .deployed in hotdeploy folder

by David Bosschaert (JIRA)

Failed OSGi deployments still show as .deployed in hotdeploy folder ------------------------------------------------------------------- Key: AS7-735 URL: https://issues.jboss.org/browse/AS7-735 Project: Application Server 7 Issue Type: Bug Components: OSGi Affects Versions: 7.0.0.CR1 Reporter: David Bosschaert Assignee: Jason Greene When deploying a bundle in AS7 in the hotdeploy directory that has missing dependencies and therefore fails the OSGi resolution process, the deployment still shows up as deployed successfully (a .deployed file appears). I think it should be marked as .failed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
15
0 / 0

[JBoss JIRA] Created: (JGRP-1302) RELAY: issues with shared transport

by Bela Ban (JIRA)

RELAY: issues with shared transport ----------------------------------- Key: JGRP-1302 URL: https://issues.jboss.org/browse/JGRP-1302 Project: JGroups Issue Type: Task Affects Versions: 2.12 Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.1 JBoss 6 creates a separate channel for each of its webapps that are marked as <distributable/> when mode=distribution. The reason is outlined in https://issues.jboss.org/browse/ISPN-658. This is a problem if we have for example a stack called "relay" (and in infinispan-configs.xml the "web" configuration refers to "relay"), and the transport is shared (singleton_name is set): - webapp web.war is deployed - A channel for web.war is created by Infinispan - The channel creates the shared transport and RELAY establishes the TCP bridge cluster as first member - Webapp SessionDemo.war is deployed - A new channel is created. The shared transport is not initialized again, as it already was for web.war - However, RELAY joins the TCP bridge cluster and thus is in the same cluster as web.war ! ==> However, both subclusters are named the same ! This leads to issues -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-1053) UNICAST: set retransmission timeout based on actual retransmission times

by Bela Ban (JIRA)

UNICAST: set retransmission timeout based on actual retransmission times ------------------------------------------------------------------------ Key: JGRP-1053 URL: https://jira.jboss.org/jira/browse/JGRP-1053 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 UNICAST needs to compute a rolling average of retransmission times, per sender (AckSenderWindow). The retransmission timeout per sender can then be set based on the actual average retransmission times. The advantage is that we throttle retransmission when we have a lot of message loss, and speed it up again when there are no message drops. The function to set the timeout should always compute the new timeot value based on (1) the old value times a decay factor and (2) a new value. The average should go up relatively quickly if the actual retransmission values go up, but come down slowly when the actual values go down. A potential function is shown below: static final double SLOW_DECAY_FACTOR=0.9, FAST_DECAY_FACTOR=0.7; static final double FAST_UP= 1 / FAST_DECAY_FACTOR, SLOW_UP= 1 / SLOW_DECAY_FACTOR; static final double SAFETY_BUFFER=0.3; static double avg=200; public static void main(String[] args) { final long[] times={200,200,400,400,500,500,500,500,500,100,100,100,100,100,100,100,100,100,100,100,100,100}; // final long[] times={200,200,200,200,200,200,200,200,200,200,200}; for(Long val: times) { double result=avg(val); System.out.println(val + ": " + result); } } private static double avg(long val) { double decay, up; if(val > avg) { decay=FAST_DECAY_FACTOR; up=FAST_UP; } else { decay=SLOW_DECAY_FACTOR; up=SLOW_UP; } double old_val=avg * decay; double result=(old_val + val * up) / 2; avg=result; return result * (1 + SAFETY_BUFFER); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-1054) NAKACK: retransmission timeouts based on actual retransmission values

by Bela Ban (JIRA)

NAKACK: retransmission timeouts based on actual retransmission values --------------------------------------------------------------------- Key: JGRP-1054 URL: https://jira.jboss.org/jira/browse/JGRP-1054 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Currently, timeouts in NAKACK are static, e.g. 300,600,1200. The goal is to make the retransmission timeouts a function of the actual average retransmission times. Ideally, we maintain rolling averages of actual retransmission times per sender and adjust the retransmit timeout based on these values. This would dynamically slow down retransmission on heavy traffic/congetion/message loss etc, and speed it up when those problems disappear again -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-1352) STATE: queue requests during state transfer

by Bela Ban (JIRA)

STATE: queue requests during state transfer ------------------------------------------- Key: JGRP-1352 URL: https://issues.jboss.org/browse/JGRP-1352 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.1 STATE should queue requests to be delivered to the application while a state transfer is in progress. Draft design: - On STATE-REQ: - If busy --> add request to queue, return - Else --> processRequest - Close MessageQueue and deliver all messages in it to the application - Kick off a STABLE round, wait until it completes - If MessageQueue is not empty --> processRequests() - processRequest(): - Close BARRIER, suspend STABLE - Get digest - Open MessageQueue: all new messages will be queued now, rather than delivered to the application - (Only MSG, not VIEW !) - Open BARRIER (leave STABLE suspended !) - Transfer state to state requester - Resume STABLE Advantages: - The state provider is not blocked, e.g. to handle JOIN requests - Only the state *requester* is blocked, this is OK though - Between the state requests, the state provider gets a little breathing room to process queued-up messages, and to purge messages (through stability) Misc: - Should the MessageQueue use the disk to handle large message sets ? - If modifications are idempotent, we *don't* need to queue messages (make this configurable !) (for example Infinispan ?) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-1354) Compress views

by Bela Ban (JIRA)

Compress views -------------- Key: JGRP-1354 URL: https://issues.jboss.org/browse/JGRP-1354 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.1 In clusters with many members, a View can be large. See if we can compress views. Possible strategies: - Canonicalization of addresses (replace UUIDs with shorts) see different JIRA) - Compress digests (see different JIRA) - Keep a list of ViewIds and Views and only send the ViewIds (not for JoinRsp !) - Create a DiffView: send the previous ViewId V1, the new ViewId V2, and the diff between V1 and V2, for example - V34=V33 + N1 + N2 - V34=V33 - N30 - N13 + N3 (2 nodes left, 1 node joined) - The receiver can then construct a full view from V34, V33 and the diffs -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-592) Pluggable policy for picking coordinator

by Bela Ban (JIRA)

Pluggable policy for picking coordinator ---------------------------------------- Key: JGRP-592 URL: http://jira.jboss.com/jira/browse/JGRP-592 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.6 Make policy to pick coordinator pluggable. Pick new coordinator after existing coordinator crashes by calling this policy. Default policy is to pick the next in line. Other policies could pick the next in line from a set of pinned coordinator, so certain members can never become coordinators. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
7
0 / 0

[JBoss JIRA] Created: (AS7-944) EJB lifecycle interceptors that are not included in the deployment are not applied

by Marius Bogoevici (JIRA)

EJB lifecycle interceptors that are not included in the deployment are not applied ---------------------------------------------------------------------------------- Key: AS7-944 URL: https://issues.jboss.org/browse/AS7-944 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.0.0.Beta3 Reporter: Marius Bogoevici Suppose that we have a class {code} @Startup @Singleton @Interceptors(A.class, B.class) public class MyEJB { } {code} Where A.class is included with the deployment and B.class is included in a module that is visible to the deployment. B will be identified correctly as an interceptor for MyEJB, but LifecycleAnnotationParsingProcessor will not process it (as it apparently handles only components found within the deployment). Therefore, B will be ignored when creating the interceptor set for MyEJB, since ComponentInstallProcessor will treat it as a class that has no lifecycle methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

4
13
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 August 2011