[JBoss JIRA] Created: (JGRP-1292) UNICAST2: resend other messages when getting request to resend first message
by Bela Ban (JIRA)
UNICAST2: resend other messages when getting request to resend first message
----------------------------------------------------------------------------
Key: JGRP-1292
URL: https://issues.jboss.org/browse/JGRP-1292
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
When A sends a unicast message to B, A's message #1 is tagged as first. This will create an entry in the receiver table of B. However, when A sends messages #1 and #2 concurrently, then #2 is probably processed first because #1 takes a bit more time to create the entry in the receiver table.
When #2 is received by B, it is discarded, as it isn't tagged as 'first', and we send a request to A to resend the first seqno.
However, until A sends message #3, or a stability message is received, A won't retransmit #2 to B. If A was an RPC, it might time out.
SOLUTION: when asking A to resend the lowest seqno, we also pass in the seqno (#2) we received, that caused us to ask A for the resend.
A will then resend all messages in the range [lowest .. seqno].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JBRULES-2707) Split up drools-guvnor into drools-guvnor-gwtclient and drools-guvnor(-server)
by Geoffrey De Smet (JIRA)
Split up drools-guvnor into drools-guvnor-gwtclient and drools-guvnor(-server)
------------------------------------------------------------------------------
Key: JBRULES-2707
URL: https://jira.jboss.org/browse/JBRULES-2707
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.2.0.M1
All classes/resources under the client/public package go to drools-guvnor-gwtclient.
The drools-guvnor-gwtclient pom.xml
- is of type war
- has only the gwt dependencies
All classes under the server package go to drools-guvnor(-server)
The drools-guvnor(-server) pom.xml
- is of type war
- has a dependency on drools-guvnor-gwtclient (= war overlay!)
- has dependencies on drools-core, drools-compiler (so on jdt too), ...
What do we do with drools-ide-common and drools-factconstraints? Split them up to, or simply move the client package code into drools-guvnor?
Where will the drools-ide-common and drools-factconstraints GWT modules be reused, besides in Guvnor?
--
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
15 years, 2 months
[JBoss JIRA] Created: (JBMETA-329) Using ejb-jar.xml for @Singleton bean
by Benoit Heinrich (JIRA)
Using ejb-jar.xml for @Singleton bean
-------------------------------------
Key: JBMETA-329
URL: https://issues.jboss.org/browse/JBMETA-329
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss AS 6.0.0.Final
Reporter: Benoit Heinrich
Hi all,
After talking on the forum about a problem with @Singleton and the use of ejb-jar.xml I've been instructed to open a bug report.
An example project is available on the jboss forum post, and can be used to reproduce the problem here.
Here is the stacktrace thrown by jboss when deploying the attached sample project:
{code}
12:48:35,699 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Real: name=vfs:///opt/src/jboss-6.0.0.Final/server/default/deploy/02-startup.ear state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error during deploy: org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:185) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1603) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_22]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_22]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_22]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_22]
Caused by: java.lang.RuntimeException: Could not resolve @EJB reference: [EJB Reference: beanInterface 'com.example.services.version.VersionManager', beanName 'null', mappedName 'null', lookupName 'null', owning unit 'ComponentDeploymentContext(a)10824652{org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean}'] for environment entry: env/ejb/VersionManager in unit ComponentDeploymentContext(a)10824652{org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean}
at org.jboss.ejb3.jndi.deployers.resource.provider.AnnotatedEJBRefResourceProvider.provide(AnnotatedEJBRefResourceProvider.java:99) [:0.1.7]
at org.jboss.ejb3.jndi.deployers.resource.provider.AnnotatedEJBRefResourceProvider.provide(AnnotatedEJBRefResourceProvider.java:50) [:0.1.7]
at org.jboss.switchboard.mc.JndiEnvironmentProcessor.process(JndiEnvironmentProcessor.java:68) [:1.0.0-alpha-15]
at org.jboss.switchboard.mc.deployer.AbstractSwitchBoardDeployer.process(AbstractSwitchBoardDeployer.java:119) [:1.0.0-alpha-15]
at org.jboss.switchboard.mc.deployer.EJBEnvironmentSwitchBoardDeployer.internalDeploy(EJBEnvironmentSwitchBoardDeployer.java:87) [:1.0.0-alpha-15]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
... 39 more
{code}
I hope it won't be too hard to fix it.
Cheers,
/Benoit
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[JBoss JIRA] Created: (JGRP-1288) FD_SOCK ignores port_range when opening server sockets
by Manuel Dominguez Sarmiento (JIRA)
FD_SOCK ignores port_range when opening server sockets
------------------------------------------------------
Key: JGRP-1288
URL: https://issues.jboss.org/browse/JGRP-1288
Project: JGroups
Issue Type: Bug
Affects Versions: 2.12
Reporter: Manuel Dominguez Sarmiento
Assignee: Bela Ban
Priority: Minor
FD_SOCK.startServerSocket() calls Util.createServerSocket(), which does not take into account a port_range. The docs for FD_SOCK state that port_range applies both for client and server socket ports. The configured value should be used instead of incrementing the port number until a free port can be bound to.
Also, the port number keeps incrementing - there's no check for MAX_PORT i.e. 65535 which could mean this could loop forever, unless an IOException is thrown before because of an invalid port number, but I don't know whether this is specified anywhere.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months