[JBoss JIRA] Created: (JGRP-1140) UNICAST based on negative acks
by Bela Ban (JIRA)
UNICAST based on negative acks
------------------------------
Key: JGRP-1140
URL: https://jira.jboss.org/jira/browse/JGRP-1140
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.10
Currently, UNICAST is based on positive acks: we send an ack for each message received. This causes a lot of ack traffic (piggybacking remedies this to a certain extent).
Investigate a version of UNICAST which uses negative acks; the sender never retransmits a message unless the receiver asks it to. The receiver only asks the sender for retransmission if it sees a missing seqno.
Issue: the last-message-lost problem. To solve it, we could exchange the last-seqno when there is no traffic any longer, e.g. by a timer task. The task would only run once, unless there's more traffic.
This is what NAKACK does, and we could even reuse the NakReceiverWindow class this ay, and eliminate AckSenderWindow and AckReceiverWindow. We could also remove DefaultRetransmitter and also use the RangeBasedRetransmitter (liek NAKACK).
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBNAME-48) Thread leak on server due to WeakReferenced Naming objects in NamingContext
by Oleg Nitz (JIRA)
Thread leak on server due to WeakReferenced Naming objects in NamingContext
---------------------------------------------------------------------------
Key: JBNAME-48
URL: https://jira.jboss.org/jira/browse/JBNAME-48
Project: JBoss Naming
Issue Type: Bug
Reporter: Oleg Nitz
Over time the number of threads named "RMI TCP Connection(...)-..." on server grows infinitely.
I discovered that this is due garbage collection of Naming objects on client, which are cached in NamingContext.cachedServers map. The correspondent server objects with their threads remain on server waiting for distributed garbage collection, which happens rarely due to "-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000" in run.conf.
I propose not use WeakReferences, instead to remove "expired" Naming objects from NamingContext.cachedServers periodically by some Timer, and also to explicitely remove correspondent remote RMI objects from server.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBAS-7807) EJB method having QName as an argument fails on jboss
by Rishi Agarwal (JIRA)
EJB method having QName as an argument fails on jboss
------------------------------------------------------
Key: JBAS-7807
URL: https://jira.jboss.org/jira/browse/JBAS-7807
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-5.1.0.GA
Environment: linux
Reporter: Rishi Agarwal
Assignee: Carlo de Wolf
I have a EJB method that has javax.xml.namespace.QName as an argument. On trying to connect to it from the jse client it gives the following exception: Our EJBs are deplyed on JBOSS AS 5.
java.lang.RuntimeException: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = -9120448754896609940, local class serialVersionUID = -711357515002332258
After removing QName class from stax-api.jar in the endorsed\lib directory , i could successfully invoke the EJB method. This is the due to the fact the QName class is available as part of JRE libraries as well and i guess this is a well-known fact that there are issue around it due to incompatible serialVersionUID.
Now my point is what is the solution to resolve this.We can't recommend removing QName class from stax-api.jar for EJBs( methods with QName as argument) to work.
--
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
16 years, 4 months
[JBoss JIRA] Assigned: (JBAS-1748) hot deploying JMX invoker service fails
by Mike Clark (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1748?page=com.atlassian.jira.plug... ]
Mike Clark reassigned JBAS-1748:
--------------------------------
Assignee: (was: Mike Clark)
> hot deploying JMX invoker service fails
> ---------------------------------------
>
> Key: JBAS-1748
> URL: https://jira.jboss.org/jira/browse/JBAS-1748
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Management services
> Affects Versions: JBossAS-4.0.2 Final
> Reporter: Norman Richards
> Priority: Minor
> Fix For: JBossAS-6.0.0.M3
>
>
> jmx-invoker-service.xml cannot be hot deployed. Trying to hot deploy it causes a failure when redeploying the web console. After this failure, I the JMX invoker cannot be contacted. Here's the resulting web console error:
> 22:49:04,904 ERROR [WebModule] Starting failed jboss.web.deployment:id=-1500951031,war=web-console.war
> java.lang.NullPointerException
> at org.jboss.web.WebModule.startModule(WebModule.java:67)
> at org.jboss.web.WebModule.startService(WebModule.java:46)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:272)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:222)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:911)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:416)
> at org.jboss.system.ServiceController.start(ServiceController.java:438)
> at org.jboss.system.ServiceController.start(ServiceController.java:438)
> at org.jboss.system.ServiceController.start(ServiceController.java:438)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:273)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:964)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:775)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
> at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
> at $Proxy8.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:325)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:483)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:204)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:215)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:194)
--
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
16 years, 4 months