June 2011 - jboss-jira - Jboss List Archives

[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, 8 months

2
6
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, 8 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, 8 months

4
13
0 / 0

[JBoss JIRA] Created: (JGRP-1340) GossipRouter: view shows mix of logical address and UUID for nodes

by Bela Ban (JIRA)

GossipRouter: view shows mix of logical address and UUID for nodes ------------------------------------------------------------------ Key: JGRP-1340 URL: https://issues.jboss.org/browse/JGRP-1340 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.2, 3.0 [Vivek Sar] On Sat, Jun 18, 2011 at 4:56 AM, Bela Ban <belaban(a)yahoo.com> wrote: > > #1 When does this happen (after a restart of a node, or on starting a new > > node) ? [vivek]: this usually happens after a node has gone out of a group (due to some intermittent network outage or communication issues) and comes back to merge into the group. We have also seen this if we restart the node without much time between stop and start (this was the example above). So, it's kind of random - it happens both for merge views and a new views. > > #2 Do the UUIDs disappear after some time, and the logical names are shown ? [vivek]: No, in my experience the UUID remain if it's the same view, but if the view changes (if any node goes in and out of a group) then the logical name come back, otherwise the UUID remains. > > #3 Does this cause any issues, other than a not-so-nice view with mixed > > logical and UUID addresses ? [vivek]: It's both - in some cases we have seen this causes node isolation - where we are not able to get the merges (see related https://issues.jboss.org/browse/JGRP-1326) - even after a node come back it's not able to merge back. In some cases, the communication is ok and it's just not-so-nice view. > > #4 What's you config ? We are using Tunnel with PING with two GRs (this is with JGroups 2.12.1), (see attached config) Thanks, -vivek > > > > On 6/17/11 10:27 PM, vivek sar wrote: >> >> >> >> Hi, >> >> >> >> We are currently using JGroups 2.12.1 with Tunnel protocol (using >> >> PING for discovery). Once in a while we see node represented using >> >> UUID rather than their logical address. I think this issue is not >> >> specific to this version of JGroups as we have seen similar problem >> >> with 2.10 as well. The problem for us is not the view logging, but >> >> different view information on different nodes - some get the logical >> >> name and others just the UUID for the same view id. In past this kind >> >> of view (showing UUIDs instead of logical address) also indicated >> >> nodes and GRs out-of-sync on the node list, which in turn was causing >> >> merge issues. >> >> >> >> Questions, >> >> >> >> 1) When does this happen - getting both logical address and UUID in >> >> the same view? >> >> 2) Why different nodes with same view id get different node >> >> information (some get UUID, while others get the right logical >> >> address)? >> >> 3) How to fix it? >> >> >> >> For ex., >> >> >> >> On Coordinator (collector_192.168.50.23): >> >> >> >> 2011-06-17 17:25:56,233 INFO >> >> [Incoming-4,192.168.50.22_group,collector_192.168.50.23:4576] >> >> RpcServiceManager - viewAccepted()-> New View: >> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576, >> >> probe_192.168.50.32:4576, probe_192.168.50.24:4576, >> >> manager_192.168.50.22:4576, probe_192.168.50.56:4576] >> >> >> >> Node 1 (manager_192.168.50.22): >> >> >> >> 2011-06-17 17:25:56,429 INFO >> >> [Incoming-5,192.168.50.22_group,manager_192.168.50.22:4576] >> >> RpcServiceManager - viewAccepted()-> New View: >> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576, >> >> 110fcd0e-6f80-7cf0-d76b-0813b913daf1, >> >> dd068d2f-ef21-1b66-1430-e8bfc862e6f9, manager_192.168.50.22:4576, >> >> probe_192.168.50.56:4576] >> >> >> >> Node 2 (probe_192.168.50.56): >> >> >> >> 2011-06-17 12:02:01,695 INFO >> >> [Incoming-10,192.168.50.22_group,probe_192.168.50.56:4576] >> >> RpcServiceManager - viewAccepted()-> New View: >> >> [collector_192.168.50.23:4576|51] [collector_192.168.50.23:4576, >> >> probe_192.168.50.32:4576, probe_192.168.50.24:4576, >> >> manager_192.168.50.22:4576, probe_192.168.50.56:4576] >> >> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

6
14
0 / 0

[JBoss JIRA] Created: (AS7-942) The CXF-DOSGi distributed discovery demo doesn't work.

by David Bosschaert (JIRA)

The CXF-DOSGi distributed discovery demo doesn't work. ------------------------------------------------------ Key: AS7-942 URL: https://issues.jboss.org/browse/AS7-942 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: David Bosschaert Priority: Minor This demo is described here: http://cxf.apache.org/dosgi-discovery-demo-page.html It seems that the client and the server bundles individually do work. The server bundle does register a remote endpoint and the client bundle does seem to look up the service, but something seems to go wrong with the interaction with the zookeeper server. I did try to configure it both through standalone.xml and load/org.apache.cxf.dosgi.diovery.zookeeper.cfg file. standalone.xml content: {code} <subsystem xmlns="urn:jboss:domain:osgi:1.0" activation="lazy"> <configuration pid="org.apache.cxf.dosgi.discovery.zookeeper"> <property name="zookeeper.host"> 127.0.0.1 </property> </configuration> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8517) Add support for two phase bundle deployments

by Thomas Diesler (JIRA)

Add support for two phase bundle deployments -------------------------------------------- Key: JBAS-8517 URL: https://jira.jboss.org/browse/JBAS-8517 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: OSGi integration Reporter: Thomas Diesler Fix For: 7.0.0.M1 In one deploy cycle, bundles must first get installed and then started. It generally needs to be discussed how multiple phase deployments should be handled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

5
24
0 / 0

[JBoss JIRA] Created: (JBRULES-2700) Allow setting globals for access by the scoring rules

by Wouter Horré (JIRA)

Allow setting globals for access by the scoring rules ----------------------------------------------------- Key: JBRULES-2700 URL: https://jira.jboss.org/browse/JBRULES-2700 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Reporter: Wouter Horré Assignee: Mark Proctor Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed. The easiest implementation is probably a new method in the Solver interface: public WorkingMemory getWorkingMemory(); which provides access to the working memory used by the solver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
17
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2035) Upport JBPAPP-2811: EJB3 timer service doesn't retry on rollback

by Carlo de Wolf (JIRA)

Upport JBPAPP-2811: EJB3 timer service doesn't retry on rollback ---------------------------------------------------------------- Key: EJBTHREE-2035 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2035 Project: EJB 3.0 Issue Type: Sub-task Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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
5
0 / 0

[JBoss JIRA] Created: (JBJCA-262) new validation warning - class are packaged inside RAR instead of JAR

by Jeff Zhang (JIRA)

new validation warning - class are packaged inside RAR instead of JAR --------------------------------------------------------------------- Key: JBJCA-262 URL: https://jira.jboss.org/jira/browse/JBJCA-262 Project: JBoss JCA Issue Type: Sub-task Components: Deployer Reporter: Jeff Zhang Assignee: Jeff Zhang -- 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
4
0 / 0

[JBoss JIRA] Created: (JGRP-495) Memory leak in NAKACK

by Bela Ban (JIRA)

Memory leak in NAKACK --------------------- Key: JGRP-495 URL: http://jira.jboss.com/jira/browse/JGRP-495 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Priority: Blocker Fix For: 2.5 Probably due to the changes introduced in NAKACK/NakReceiverWindow (http://jira.jboss.com/jira/browse/JGRP-281). To reproduce, run perf.Test on 2 nodes with 1 million 1K messages each. JProfiler shows that we are leaking Map.Entry instances in NAKACK. They seem to accumulate in xmit_table. -- 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

2
3
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 June 2011