May 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-1282) ServerInvoker does not close StreamHandler in the case of "addstreamcallback"

by Ramesh Reddy (JIRA)

ServerInvoker does not close StreamHandler in the case of "addstreamcallback" ----------------------------------------------------------------------------- Key: JBREM-1282 URL: https://issues.jboss.org/browse/JBREM-1282 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.1 (Flounder) Reporter: Ramesh Reddy Attachments: JBossRemoting.patch This started out http://community.jboss.org/thread/163742 and in Teiid project we created a JIRA for this https://issues.jboss.org/browse/TEIID-1511 while debugging for this issue, I found that in ServerInvoker, for "AddStreamCallback" block in the "handleInternalInvocation" method it does not close the stream handler once it is done. This results in open socket connection. I am not sure if this connection closes after some idle time, but in our case user is rapidly going through deploy and undeploy action, results in too many open files. I created a patch and tested with our usecase, the problem no longer exists. Please find attached patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
15
0 / 0

[JBoss JIRA] Created: (JBRULES-2999) When using fusion's 'after' or 'before' operator the ConsequenceException (caused by NPE) is thrown.

by Tihomir Surdilovic (JIRA)

When using fusion's 'after' or 'before' operator the ConsequenceException (caused by NPE) is thrown. ---------------------------------------------------------------------------------------------------- Key: JBRULES-2999 URL: https://issues.jboss.org/browse/JBRULES-2999 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M2 Reporter: Tihomir Surdilovic Assignee: Edson Tirelli Priority: Blocker When using 'after' or 'before' operator (maybe also other operators) in simple rule, the ConseqeunceException (cased by NPE) is thrown. The rule and simple test that reproduce this exception are attached. I discussed this with Edson Tirelli and it's a regression. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2504) Maven: clean up the maven build and prepare for maven 3 (multi-issue)

by Geoffrey De Smet (JIRA)

Maven: clean up the maven build and prepare for maven 3 (multi-issue) --------------------------------------------------------------------- Key: JBRULES-2504 URL: https://jira.jboss.org/jira/browse/JBRULES-2504 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.0.M1 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Minor Fix For: FUTURE This is a list of the smaller issues: * Don't use compile dependencies for dependencies that should be purely transitive dependencies * Don't use <optional> in <dependencyManagement> ** might not already be the case * All of the generated files should be in the target directory ** guvnor: version file etc ** several modules (osgi based?): MANIFEST.MF Bigger issues are linked. -- 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

12 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2703) AllBestSolutionsRecaller: Drools Planner should support returning all the solutions with the same best score found during solving, not just the first

by Geoffrey De Smet (JIRA)

AllBestSolutionsRecaller: Drools Planner should support returning all the solutions with the same best score found during solving, not just the first ----------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2703 URL: https://jira.jboss.org/browse/JBRULES-2703 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.1.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.2.0.M1 Extra method on Solver: getBestSolutions(). Maybe rename BestSolutionRecaller to AllBestSolutionsRecaller? I wouldn't keep the first if a couple experiments should little or no performance degradation due to the hashing of each solution step (especially in sim ann). What do we do with Solver.getBestSolution()? Proposition 1: remove it Proposition 2: keep it and return getBestSolutions().get(0) -- 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

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2043) Log problems while building the RuleBase

by Dietmar Scheidl (JIRA)

Log problems while building the RuleBase ---------------------------------------- Key: JBRULES-2043 URL: https://jira.jboss.org/jira/browse/JBRULES-2043 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-solver Affects Versions: 5.0.0.M5 Reporter: Dietmar Scheidl Assignee: Mark Proctor I startet to experiment with the drools-solver but only got a NullPointerException: Caused by: java.lang.NullPointerException at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:429) at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:395) at org.drools.solver.config.localsearch.LocalSearchSolverConfig.buildRuleBase(LocalSearchSolverConfig.java:166) at org.drools.solver.config.localsearch.LocalSearchSolverConfig.buildSolver(LocalSearchSolverConfig.java:137) at org.drools.solver.config.XmlSolverConfigurer.buildSolver(XmlSolverConfigurer.java:73) ... After debugging into this location, I found out that it comes from an error in my scoreDrl. The buildSolver-Method should fail with a more helpful exception or the result of the PackageBuilder should be available to analyse the problems. -- 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

12 years, 11 months

4
13
0 / 0

[JBoss JIRA] Created: (JBCOMMON-117) Race-condition leads to IllegalStateException Cache list entries number (x) > than the maximum allowed (x-1)

by Rico Neubauer (JIRA)

Race-condition leads to IllegalStateException Cache list entries number (x) > than the maximum allowed (x-1) ------------------------------------------------------------------------------------------------------------ Key: JBCOMMON-117 URL: https://issues.jboss.org/browse/JBCOMMON-117 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-core (2.x) Affects Versions: 2.2.17.GA, 2.2.18.GA Reporter: Rico Neubauer Attachments: JBCOMMON-117.diff org.jboss.util.LRUCachePolicy takes care of a cache with a maxCapacity. Unfortunately the modifications of the count of entries is not thread-safe and might lead to the situation that the cache holds more than maxCapacity entries. This can only be seen rarely under heavy load on SMP machines; so far the count reached at most maxCapacity+1, but it's imaginable it could go beyond. One possibility is to fix the modifications of count, which should preferably NOT introduce synchronizations. Another simpler approach is to not throw the exception in case of the cache already having crossed the limit (which itself does not error-out), but behave nicely, since there are no real implications and the limit is not considered to be needed that strict imho. I will attach a proposed patch, showing the problem and using the latter option to fix it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-9341) Datasource attribute "enabled" not writable

by Heiko Braun (JIRA)

Datasource attribute "enabled" not writable ------------------------------------------- Key: JBAS-9341 URL: https://issues.jboss.org/browse/JBAS-9341 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Reporter: Heiko Braun Assignee: Stefano Maestri Fix For: 7.0.0.Beta4 [localhost:9999 /] /profile=default/subsystem=datasources/data-source=myDS:write-attribute(name=enabled, value=false) { "outcome" => "failed", "result" => {"domain-failure-description" => "Attribute enabled is not writeable"} } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
8
0 / 0

[JBoss JIRA] Created: (AS7-709) update commands creating JMS resources to work in domain

by Alexey Loubyansky (JIRA)

update commands creating JMS resources to work in domain -------------------------------------------------------- Key: AS7-709 URL: https://issues.jboss.org/browse/AS7-709 Project: Application Server 7 Issue Type: Task Components: CLI Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.0.0.CR1 create-jms-cf, create-jms-topic, create-jms-queue currently work only for standalone. In the domain mode they are missing the profile argument. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] Deleted: (AS7-717) support of @DataSourceDefinition

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/AS7-717?page=com.atlassian.jira.plugin.sy... ] Stefano Maestri deleted AS7-717: -------------------------------- > support of @DataSourceDefinition > -------------------------------- > > Key: AS7-717 > URL: https://issues.jboss.org/browse/AS7-717 > Project: Application Server 7 > Issue Type: Task > Reporter: Stefano Maestri > Assignee: Stefano Maestri > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1847) JBoss shutdown hangs to be caused by deadlock between "JBoss Shutdown Hook" and "WorkerThread"

by Masafumi Miura (JIRA)

JBoss shutdown hangs to be caused by deadlock between "JBoss Shutdown Hook" and "WorkerThread" ---------------------------------------------------------------------------------------------- Key: JBMESSAGING-1847 URL: https://issues.jboss.org/browse/JBMESSAGING-1847 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3_CP03 Reporter: Masafumi Miura Fix For: 1.4.0.SP3.CP12 JBoss shutdown hangs to be caused by deadlock between "JBoss Shutdown Hook" and JBoss Messaging "WorkerThread" "JBoss Shutdown Hook" daemon prio=1 tid=0x0a023258 nid=0x2a38 in Object.wait() [0x826f8000..0x826fa130] at java.lang.Object.wait(Native Method) - waiting on <0x91593088> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at java.lang.Object.wait(Object.java:474) at EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(WriterPreferenceReadWriteLock.java:240) - locked <0x91593088> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.setClosed(JMSServerInvocationHandler.java:68) at org.jboss.jms.server.ServerPeer.stopService(ServerPeer.java:349) - locked <0x914cd0a0> (a org.jboss.jms.server.ServerPeer) at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315) at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:206) at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995) at $Proxy0.stop(Unknown Source) at org.jboss.system.ServiceController.stop(ServiceController.java:508) at org.jboss.system.ServiceController.stop(ServiceController.java:499) at org.jboss.system.ServiceController.stop(ServiceController.java:499) at org.jboss.system.ServiceController.stop(ServiceController.java:499) at org.jboss.system.ServiceController.stop(ServiceController.java:499) at org.jboss.system.ServiceController.stop(ServiceController.java:499) at org.jboss.system.ServiceController.stop(ServiceController.java:499) 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:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.stop(Unknown Source) at org.jboss.deployment.SARDeployer.stop(SARDeployer.java:336) 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:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy42.stop(Unknown Source) at org.jboss.deployment.XSLSubDeployer.stop(XSLSubDeployer.java:202) at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667) at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638) at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:516) 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:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:1058) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1033) at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996) "WorkerThread#12[10.133.46.128:50365]" prio=1 tid=0x0badb610 nid=0x1077 waiting for monitor entry [0x85657000..0x85657eb0] at org.jboss.jms.server.ServerPeer.getDefaultDLQInstance(ServerPeer.java:1187) - waiting to lock <0x914cd0a0> (a org.jboss.jms.server.ServerPeer) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.<init>(ServerSessionEndpoint.java:220) at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:249) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$createSessionDelegate$aop(ConnectionAdvised.java:75) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$createSessionDelegate_6052335267724906805.invokeNext(ConnectionAdvised$createSessionDelegate_6052335267724906805.java) at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$createSessionDelegate_6052335267724906805.invokeNext(ConnectionAdvised$createSessionDelegate_6052335267724906805.java) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.createSessionDelegate(ConnectionAdvised.java) at org.jboss.jms.wireformat.ConnectionCreateSessionDelegateRequest.serverInvoke(ConnectionCreateSessionDelegateRequest.java:87) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:608) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:420) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2011