[JBoss JIRA] (AS7-6367) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Alexey Tomin (JIRA)
[ https://issues.jboss.org/browse/AS7-6367?page=com.atlassian.jira.plugin.s... ]
Alexey Tomin commented on AS7-6367:
-----------------------------------
Need also add different setting for jms (hornetq) connection....
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6367
> URL: https://issues.jboss.org/browse/AS7-6367
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Derek Horton
> Assignee: jaikiran pai
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
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, 1 month
[JBoss JIRA] (DROOLS-81) Drools freezes during execution
by Andrew kelly (JIRA)
Andrew kelly created DROOLS-81:
----------------------------------
Summary: Drools freezes during execution
Key: DROOLS-81
URL: https://issues.jboss.org/browse/DROOLS-81
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5
Reporter: Andrew kelly
Assignee: Mark Proctor
When Drools is being run to process rules on a number of threads on occasion the rules engine freezes with the stack trace below and does not complete. There are a number of other threads that are also frozen out waiting to lock 0x00002aab9d4caf58:
Frozen Thread
"pool-3-thread-8" prio=10 tid=0x00002ab53d16e000 nid=0x1c29 runnable [0x0000000049fc7000]
java.lang.Thread.State: RUNNABLE
at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:408)
- locked \<0x00002aab9d4caf58\> (a java.lang.ref.ReferenceQueue)
at java.util.WeakHashMap.getTable(WeakHashMap.java:417)
at java.util.WeakHashMap.get(WeakHashMap.java:464)
at org.mvel2.util.ParseTools.getBestCandidate(ParseTools.java:241)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1039)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:987)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:377)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:143)
at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
at org.mvel2.MVEL.executeExpression(MVEL.java:930)
at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:104)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
- locked \<0x00002aaec5b1b160\> (a org.drools.common.DefaultAgenda)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
at com.iontrading.arc.liquidityrules.engine.BatchRulesEngine.processAll(BatchRulesEngine.java:64)
at com.iontrading.arc.liquidityrules.api.rulestoresource.AbstractRuleStoreSourceService.performBaselineProcessing(AbstractRuleStoreSourceService.java:860)
at com.rbc.erm.rulestoresource.RuleStoreSourceService.access$600(RuleStoreSourceService.java:32)
at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:66)
at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:38)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Example of other frozen threads:
"pool-3-thread-9" prio=10 tid=0x00002ab53d16f800 nid=0x1c2a waiting for monitor entry [0x000000004a0c9000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:386)
- waiting to lock \<0x00002aab9d4caf58\> (a java.lang.ref.ReferenceQueue)
at java.util.WeakHashMap.getTable(WeakHashMap.java:417)
at java.util.WeakHashMap.get(WeakHashMap.java:464)
at org.mvel2.util.ParseTools.getBestCandidate(ParseTools.java:241)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1039)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:987)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:377)
at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:143)
at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
at org.mvel2.MVEL.executeExpression(MVEL.java:930)
at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:104)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
- locked \<0x00002aaeedca2870\> (a org.drools.common.DefaultAgenda)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
at com.iontrading.arc.liquidityrules.engine.BatchRulesEngine.processAll(BatchRulesEngine.java:64)
at com.rbc.erm.rulestoresource.RuleStoreSourceService.performViewProcessing(RuleStoreSourceService.java:133)
at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:78)
at com.rbc.erm.rulestoresource.RuleStoreSourceService$RuleStoreProcess.call(RuleStoreSourceService.java:38)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
--
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, 1 month
[JBoss JIRA] (AS7-6742) CommandLineConsole: ls in subsystem=datasources causing java.lang.ArithmeticException: / by zero
by Chao Wang (JIRA)
Chao Wang created AS7-6742:
------------------------------
Summary: CommandLineConsole: ls in subsystem=datasources causing java.lang.ArithmeticException: / by zero
Key: AS7-6742
URL: https://issues.jboss.org/browse/AS7-6742
Project: Application Server 7
Issue Type: Bug
Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
Reporter: Chao Wang
Assignee: Chao Wang
Fix For: 8.0.0.Alpha1
Description of problem:
Version-Release number of selected component (if applicable):
eap6.1.0.DR4
Steps to Reproduce:
1.run fresh jboss instance
2.connect to it with jboss-cli
3.cd subsystem=datasources
4.ls
Additional info:
java.lang.ArithmeticException: / by zero
at org.jboss.aesh.util.Parser.formatDisplayList(Parser.java:70)
at org.jboss.aesh.util.Parser.formatDisplayList(Parser.java:43)
at org.jboss.as.cli.impl.Console$Factory$1.printColumns(Console.java:146)
at org.jboss.as.cli.impl.CommandContextImpl.printColumns(CommandContextImpl.java:713)
at org.jboss.as.cli.handlers.CommandHandlerWithHelp.printList(CommandHandlerWithHelp.java:128)
at org.jboss.as.cli.handlers.LsHandler.doHandle(LsHandler.java:355)
at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86)
at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581)
at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:597)
at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1185)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:259)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.modules.Module.run(Module.java:262)
at org.jboss.modules.Main.main(Main.java:329)
--
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, 1 month
[JBoss JIRA] (AS7-6741) Module query mechanism to prevent inadvertent uninstallation.
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6741?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6741:
--------------------------------
Assignee: (was: Thomas Diesler)
Component/s: Server
(was: ConfigAdmin)
> Module query mechanism to prevent inadvertent uninstallation.
> -------------------------------------------------------------
>
> Key: AS7-6741
> URL: https://issues.jboss.org/browse/AS7-6741
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.0.0.Alpha1
> Environment: All environments.
> Reporter: Jeremy Whiting
> Priority: Minor
>
> This feature request is to add the ability to query a deployment module. Good examples for this feature are jbosstm or hornetq but not limited to them.
> A module that has saved files or meta-data to ensure application data consistency needs to prevent the un-installation of the module. Typically these are crash recovery records that have heuristic failures and cannot be automatically resolved when the system starts. When the records have been resolved and no longer necessary the deployment can be removed.
> This feature means users/operators that manage installations do not inadvertently make matters worse by upgrading a module which cannot read an existing/written record format.
> The un-installation could be forcefully removed by for example clicking a checkbox in a GUI and a data health warning displayed.
--
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, 1 month
[JBoss JIRA] (AS7-6741) Module query mechanism to prevent inadvertent uninstallation.
by Jeremy Whiting (JIRA)
Jeremy Whiting created AS7-6741:
-----------------------------------
Summary: Module query mechanism to prevent inadvertent uninstallation.
Key: AS7-6741
URL: https://issues.jboss.org/browse/AS7-6741
Project: Application Server 7
Issue Type: Feature Request
Components: ConfigAdmin
Affects Versions: 8.0.0.Alpha1
Environment: All environments.
Reporter: Jeremy Whiting
Assignee: Thomas Diesler
Priority: Minor
This feature request is to add the ability to query a deployment module. Good examples for this feature are jbosstm or hornetq but not limited to them.
A module that has saved files or meta-data to ensure application data consistency needs to prevent the un-installation of the module. Typically these are crash recovery records that have heuristic failures and cannot be automatically resolved when the system starts. When the records have been resolved and no longer necessary the deployment can be removed.
This feature means users/operators that manage installations do not inadvertently make matters worse by upgrading a module which cannot read an existing/written record format.
The un-installation could be forcefully removed by for example clicking a checkbox in a GUI and a data health warning displayed.
--
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, 1 month
[JBoss JIRA] (AS7-6187) NullPointerException during SAR Service deployment
by Guy Kaisin (JIRA)
[ https://issues.jboss.org/browse/AS7-6187?page=com.atlassian.jira.plugin.s... ]
Guy Kaisin commented on AS7-6187:
---------------------------------
OOps, forgot to indicate the build...
To verify the issue I used https://ci.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x/ build 3436.
KR,
G.
> NullPointerException during SAR Service deployment
> --------------------------------------------------
>
> Key: AS7-6187
> URL: https://issues.jboss.org/browse/AS7-6187
> Project: Application Server 7
> Issue Type: Bug
> Components: Naming
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Guy Kaisin
> Assignee: Eduardo Martins
>
> Hi all,
> Still continuing to test/verify how to use mbean...
> Here is now how I implement the bind/rebind:
> <code>
> private void rebind() throws NamingException
> {
> InitialContext rootCtx = new InitialContext();
> Name fullName = rootCtx.getNameParser("").parse(getFullJndiName());
> ServiceName servName=ServiceName.parse(getFullJndiName());
> WritableServiceBasedNamingStore.pushOwner(servName);
> try
> {
> logger.info("fullName=" + fullName+" -> rebind ...");
> org.jboss.util.naming.NonSerializableFactory.rebind(fullName, sHelper, true);
> logger.info("fullName=" + fullName+" -> rebind ok");
> }
> catch(NamingException ex)
> { ex.printStackTrace(); throw ex; }
> finally
> { WritableServiceBasedNamingStore.popOwner(); }
> }
> </code>
> Like that, I don't have the 'context is read only' issue any more.
> But I get another exception...
> 13:54:54,997 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
> t.mid.dao.AddressDAO
> 13:54:55,012 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
> t.mid.dao.AddressDAO -> rebind ...
> 13:54:55,013 ERROR [stderr] (MSC service thread 1-2) javax.naming.NamingException: Failed to bind [Reference Class Name:
> be.post.common.servicelocator.helper.ServiceHelper
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Type: nns
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Content: java:global/mid/be.post.mid.dao.AddressDAO
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) ] at location [service jboss.naming.context.java.global.mid."be.pos
> t.mid.dao.AddressDAO"] [Root exception is java.lang.NullPointerException]
> 13:54:55,015 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.util.NamingUtils.namingException(NamingUt
> ils.java:151)
> 13:54:55,061 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
> ableServiceBasedNamingStore.java:80)
> 13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(Wr
> itableServiceBasedNamingStore.java:95)
> 13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
> 61)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.InitialContext.rebind(InitialContext.java
> :158)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
> 69)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at javax.naming.InitialContext.rebind(InitialContext.java:408)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
> izableFactory.java:185)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
> izableFactory.java:250)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.jav
> a:72)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.startService(JndiBind
> er.java:52)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(Servi
> ceMBeanSupport.java:250)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSuppor
> t.java:158)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(Serv
> iceMBeanSupport.java:229)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSuppo
> rt.java:154)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBea
> nSupport.java:364)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSuppor
> t.java:192)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postReg
> isterInvoke(DefaultMBeanServerInterceptor.java:1035)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rDynamicMBean(DefaultMBeanServerInterceptor.java:974)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rObject(DefaultMBeanServerInterceptor.java:917)
> 13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rMBean(DefaultMBeanServerInterceptor.java:312)
> 13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBean
> Server.java:482)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.reg
> isterMBean(PluggableMBeanServerImpl.java:551)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(Plugg
> ableMBeanServerImpl.java:319)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistra
> tionService.java:90)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startSe
> rvice(ServiceControllerImpl.java:1811)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(Ser
> viceControllerImpl.java:1746)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Thread
> PoolExecutor.java:886)
> 13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool
> Executor.java:908)
> 13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.lang.Thread.run(Thread.java:662)
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) Caused by: java.lang.NullPointerException
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
> ableServiceBasedNamingStore.java:77)
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) ... 28 more
> 13:54:55,076 WARN [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) Starting failed mid.services.da
> o:service=AddressDAOMBean: javax.naming.NamingException: Failed to bind [Reference Class Name: be.post.common.serviceloc
> ator.helper.ServiceHelper
> Type: nns
> Content: java:global/mid/be.post.mid.dao.AddressDAO
> ] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
> ullPointerException]
> at org.jboss.as.naming.util.NamingUtils.namingException(NamingUtils.java:151)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:80)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:95)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:261)
> at org.jboss.as.naming.InitialContext.rebind(InitialContext.java:158)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:269)
> at javax.naming.InitialContext.rebind(InitialContext.java:408) [rt.jar:1.6.0_25]
> at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:185)
> at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:250)
> at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.java:72)
> at be.post.common.servicebinder.JndiBinder.startService(JndiBinder.java:52)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:250)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:158)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:229)
> at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:154)
> at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBeanSupport.java:364)
> at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSupport.java:192) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1
> 035) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java
> :974) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
> [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) [
> rt.jar:1.6.0_25]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) [rt.jar:1.6.0_25]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:551) [j
> boss-as-jmx-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:319) [jboss-as-jmx-7.2.
> 0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:90) [jboss-as-jmx-7.2.0.Alpha1-
> SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-ms
> c-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.G
> A.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:77)
> ... 28 more
> 13:54:55,087 ERROR [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) javax.naming.NamingException: F
> ailed to bind [Reference Class Name: be.post.common.servicelocator.helper.ServiceHelper
> Type: nns
> Content: java:global/mid/be.post.mid.dao.AddressDAO
> ] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
> ullPointerException]
> I use a jboss-service.xml file, containing the following:
> <mbean name="mid.services.dao:service=AddressDAOMBean"
> code="be.post.common.servicebinder.DaoJndiBinder">
> <attribute name="JndiName">be.post.mid.dao.AddressDAO</attribute>
> <attribute name="DataSourceJndiName">java:MIDCoreOracleDS</attribute>
> <attribute name="InterfaceClass">be.post.mid.dao.AddressDAO</attribute>
> <attribute name="ImplementationClass">be.post.mid.dao.oracle.AddressOracle</attribute>
> </mbean>
> I could identify the line giving the exception:
> // add the service name to runtime bindings management service, which on stop releases the services.
> final Set<ServiceName> duBindingReferences = (Set<ServiceName> getServiceRegistry().getService(JndiNamingDependencyProcessor.serviceName(deploymentUnitServiceName)).getValue();
> But what is the root cause of it?
> any suggestion?
> thanks a lot...
--
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, 1 month
[JBoss JIRA] (AS7-6187) NullPointerException during SAR Service deployment
by Guy Kaisin (JIRA)
[ https://issues.jboss.org/browse/AS7-6187?page=com.atlassian.jira.plugin.s... ]
Guy Kaisin closed AS7-6187.
---------------------------
Hi all,
Just verified the solution and... good news: it's working!
> NullPointerException during SAR Service deployment
> --------------------------------------------------
>
> Key: AS7-6187
> URL: https://issues.jboss.org/browse/AS7-6187
> Project: Application Server 7
> Issue Type: Bug
> Components: Naming
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Guy Kaisin
> Assignee: Eduardo Martins
>
> Hi all,
> Still continuing to test/verify how to use mbean...
> Here is now how I implement the bind/rebind:
> <code>
> private void rebind() throws NamingException
> {
> InitialContext rootCtx = new InitialContext();
> Name fullName = rootCtx.getNameParser("").parse(getFullJndiName());
> ServiceName servName=ServiceName.parse(getFullJndiName());
> WritableServiceBasedNamingStore.pushOwner(servName);
> try
> {
> logger.info("fullName=" + fullName+" -> rebind ...");
> org.jboss.util.naming.NonSerializableFactory.rebind(fullName, sHelper, true);
> logger.info("fullName=" + fullName+" -> rebind ok");
> }
> catch(NamingException ex)
> { ex.printStackTrace(); throw ex; }
> finally
> { WritableServiceBasedNamingStore.popOwner(); }
> }
> </code>
> Like that, I don't have the 'context is read only' issue any more.
> But I get another exception...
> 13:54:54,997 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
> t.mid.dao.AddressDAO
> 13:54:55,012 INFO [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) fullName=java:global/mid/be.pos
> t.mid.dao.AddressDAO -> rebind ...
> 13:54:55,013 ERROR [stderr] (MSC service thread 1-2) javax.naming.NamingException: Failed to bind [Reference Class Name:
> be.post.common.servicelocator.helper.ServiceHelper
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Type: nns
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) Content: java:global/mid/be.post.mid.dao.AddressDAO
> 13:54:55,014 ERROR [stderr] (MSC service thread 1-2) ] at location [service jboss.naming.context.java.global.mid."be.pos
> t.mid.dao.AddressDAO"] [Root exception is java.lang.NullPointerException]
> 13:54:55,015 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.util.NamingUtils.namingException(NamingUt
> ils.java:151)
> 13:54:55,061 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
> ableServiceBasedNamingStore.java:80)
> 13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(Wr
> itableServiceBasedNamingStore.java:95)
> 13:54:55,066 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
> 61)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.InitialContext.rebind(InitialContext.java
> :158)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:2
> 69)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at javax.naming.InitialContext.rebind(InitialContext.java:408)
> 13:54:55,067 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
> izableFactory.java:185)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerial
> izableFactory.java:250)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.jav
> a:72)
> 13:54:55,068 ERROR [stderr] (MSC service thread 1-2) at be.post.common.servicebinder.JndiBinder.startService(JndiBind
> er.java:52)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(Servi
> ceMBeanSupport.java:250)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSuppor
> t.java:158)
> 13:54:55,069 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(Serv
> iceMBeanSupport.java:229)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSuppo
> rt.java:154)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBea
> nSupport.java:364)
> 13:54:55,070 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSuppor
> t.java:192)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postReg
> isterInvoke(DefaultMBeanServerInterceptor.java:1035)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rDynamicMBean(DefaultMBeanServerInterceptor.java:974)
> 13:54:55,071 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rObject(DefaultMBeanServerInterceptor.java:917)
> 13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registe
> rMBean(DefaultMBeanServerInterceptor.java:312)
> 13:54:55,072 ERROR [stderr] (MSC service thread 1-2) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBean
> Server.java:482)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.reg
> isterMBean(PluggableMBeanServerImpl.java:551)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(Plugg
> ableMBeanServerImpl.java:319)
> 13:54:55,073 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistra
> tionService.java:90)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startSe
> rvice(ServiceControllerImpl.java:1811)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(Ser
> viceControllerImpl.java:1746)
> 13:54:55,074 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Thread
> PoolExecutor.java:886)
> 13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool
> Executor.java:908)
> 13:54:55,075 ERROR [stderr] (MSC service thread 1-2) at java.lang.Thread.run(Thread.java:662)
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) Caused by: java.lang.NullPointerException
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(Writ
> ableServiceBasedNamingStore.java:77)
> 13:54:55,076 ERROR [stderr] (MSC service thread 1-2) ... 28 more
> 13:54:55,076 WARN [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) Starting failed mid.services.da
> o:service=AddressDAOMBean: javax.naming.NamingException: Failed to bind [Reference Class Name: be.post.common.serviceloc
> ator.helper.ServiceHelper
> Type: nns
> Content: java:global/mid/be.post.mid.dao.AddressDAO
> ] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
> ullPointerException]
> at org.jboss.as.naming.util.NamingUtils.namingException(NamingUtils.java:151)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:80)
> at org.jboss.as.naming.WritableServiceBasedNamingStore.rebind(WritableServiceBasedNamingStore.java:95)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:261)
> at org.jboss.as.naming.InitialContext.rebind(InitialContext.java:158)
> at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:269)
> at javax.naming.InitialContext.rebind(InitialContext.java:408) [rt.jar:1.6.0_25]
> at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:185)
> at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:250)
> at be.post.common.servicebinder.JndiBinder.rebind(JndiBinder.java:72)
> at be.post.common.servicebinder.JndiBinder.startService(JndiBinder.java:52)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:250)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:158)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:229)
> at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:154)
> at org.jboss.system.ServiceMBeanSupport.postRegister(ServiceMBeanSupport.java:364)
> at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSupport.java:192) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1
> 035) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java
> :974) [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
> [rt.jar:1.6.0_25]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) [
> rt.jar:1.6.0_25]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) [rt.jar:1.6.0_25]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:551) [j
> boss-as-jmx-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:319) [jboss-as-jmx-7.2.
> 0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:90) [jboss-as-jmx-7.2.0.Alpha1-
> SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-ms
> c-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.G
> A.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:77)
> ... 28 more
> 13:54:55,087 ERROR [be.post.common.servicebinder.DaoJndiBinder] (MSC service thread 1-2) javax.naming.NamingException: F
> ailed to bind [Reference Class Name: be.post.common.servicelocator.helper.ServiceHelper
> Type: nns
> Content: java:global/mid/be.post.mid.dao.AddressDAO
> ] at location [service jboss.naming.context.java.global.mid."be.post.mid.dao.AddressDAO"] [Root exception is java.lang.N
> ullPointerException]
> I use a jboss-service.xml file, containing the following:
> <mbean name="mid.services.dao:service=AddressDAOMBean"
> code="be.post.common.servicebinder.DaoJndiBinder">
> <attribute name="JndiName">be.post.mid.dao.AddressDAO</attribute>
> <attribute name="DataSourceJndiName">java:MIDCoreOracleDS</attribute>
> <attribute name="InterfaceClass">be.post.mid.dao.AddressDAO</attribute>
> <attribute name="ImplementationClass">be.post.mid.dao.oracle.AddressOracle</attribute>
> </mbean>
> I could identify the line giving the exception:
> // add the service name to runtime bindings management service, which on stop releases the services.
> final Set<ServiceName> duBindingReferences = (Set<ServiceName> getServiceRegistry().getService(JndiNamingDependencyProcessor.serviceName(deploymentUnitServiceName)).getValue();
> But what is the root cause of it?
> any suggestion?
> thanks a lot...
--
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, 1 month
[JBoss JIRA] (JBRULES-3713) UnsupportedOperationException from BaseLeftTuple.getBlocker
by Matt Strum (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3713?page=com.atlassian.jira.plug... ]
Matt Strum commented on JBRULES-3713:
-------------------------------------
I have seen the exact same problem on 5.5.0.Final. Similar to the older issue, it fixes itself if I make the package name a single word.
> UnsupportedOperationException from BaseLeftTuple.getBlocker
> -----------------------------------------------------------
>
> Key: JBRULES-3713
> URL: https://issues.jboss.org/browse/JBRULES-3713
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Ryan Crumley
> Assignee: Mark Proctor
>
> I am occasionally running into the follow exception after upgrading from 5.4.0-Final to 5.5.0-Final:
> Caused by: java.lang.UnsupportedOperationException
> at org.drools.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:556)
> at org.drools.reteoo.NotNode.modifyLeftTuple(NotNode.java:234)
> at org.drools.reteoo.LeftTupleSource.doModifyLeftTuple(LeftTupleSource.java:304)
> at org.drools.reteoo.LeftTupleSource.modifyLeftTuple(LeftTupleSource.java:278)
> at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateModifyLeftTuple(SingleLeftTupleSinkAdapter.java:205)
> at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyObject(SingleLeftTupleSinkAdapter.java:235)
> at org.drools.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:170)
> at org.drools.reteoo.SingleObjectSinkAdapter.propagateModifyObject(SingleObjectSinkAdapter.java:68)
> at org.drools.reteoo.AlphaNode.modifyObject(AlphaNode.java:157)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:507)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:432)
> at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:314)
> at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:265)
> at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:483)
> at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:383)
> at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:337)
> Please let me know what else I can provide to help debug. I can provide a small project to reproduce if needed.
--
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, 1 month
[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1317?page=com.atlassian.jira.plugin... ]
Ron Sigal commented on JBREM-1317:
----------------------------------
I was wrong about Client.close(), which doesn't exist. It's Client.disconnect() that leads to steps 2 - 6.
Howard Gao has commented on step 1:
"The JBM on notification will shutdown the callback handler which calls callbackClient.disconnect()"
So, I believe that this issue is already effectively solved.
> BisocketClientInvoker waits for failed clients
> ----------------------------------------------
>
> Key: JBREM-1317
> URL: https://issues.jboss.org/browse/JBREM-1317
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: callbacks
> Affects Versions: 2.5.4.SP3
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Priority: Minor
>
> When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker:
> (NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe
> The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however.
> The code carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list.
> This results in the code waiting for the full duration of the configured timeout.
--
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, 1 month