October 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBMESSAGING-1898) MessageProxy's log member should be static

by Yong Hao Gao (Created) (JIRA)

MessageProxy's log member should be static ------------------------------------------ Key: JBMESSAGING-1898 URL: https://issues.jboss.org/browse/JBMESSAGING-1898 Project: JBoss Messaging Issue Type: Bug Components: JMS Facade Affects Versions: 1.4.8.SP3, 1.4.0.SP3.CP14 Reporter: Yong Hao Gao Assignee: Yong Hao Gao Fix For: 1.4.0.SP3.CP15, 1.4.8.SP4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
2
0 / 0

[JBoss JIRA] (AS7-2034) Asynchronous EJB thread pool maximum size is set to "Runtime.getRuntime().availableProcessors()"

by Stian Thorgersen (Created) (JIRA)

Asynchronous EJB thread pool maximum size is set to "Runtime.getRuntime().availableProcessors()" ------------------------------------------------------------------------------------------------ Key: AS7-2034 URL: https://issues.jboss.org/browse/AS7-2034 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.2.Final Reporter: Stian Thorgersen Attachments: agility-async_test.jar, AsyncBean.java, InvokerBean.java The thread pool service used to execute @Asynchronous EJB methods have been set to "Runtime.getRuntime().availableProcessors()". This is clearly not a sensible default as on a single core CPU (or VM) only a single @Asynchronous method is executed concurrently. I would imagine a sensible default would be at least 10. It would also be very useful if it was possible set this value in the configuration files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

5
6
0 / 0

[JBoss JIRA] Created: (JBRULES-3211) Rules fires on incorrect condition

by Tommy Odom (JIRA)

Rules fires on incorrect condition ---------------------------------- Key: JBRULES-3211 URL: https://issues.jboss.org/browse/JBRULES-3211 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.2.0.Final Reporter: Tommy Odom Assignee: Mark Proctor We are running into some issues after upgrading to Drools 5.2.0 from Drools 5.1.1. Our rules are no longer executing correctly. The wrong rule fires due to the constraints of a previous rule. I wrote a standalone test that replicates the problem and I've tested with 5.3.0-SNAPSHOT and the tests fail there as well. Forgive me if what I state is incorrect but I figured I'd try to relay some of what I observed in debugging. It appears that the difference between 5.1.1 and 5.2.0 comes from the handling of the constraints. In 5.1.1, the constraints were created as PredicateConstraints but in 5.2.0 they are being created as LiteralConstraints. As such, in 5.1.1 in the CompositeObjectSinkAdapter adds the new sinks as otherSinks but in 5.2.0 they are registered as FieldIndexes. However, the index value on all of the MVELClassFieldReader instances is 0 so both "engine.engineType.id" and "engine.id" are mapped to the same FieldIndex. I haven't had time yet to dig into the code to understand the difference between a PredicateConstraint and a LiteralConstraint so I'm not sure if there's something I could be doing differently to avoid this problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
3
0 / 0

[JBoss JIRA] (JBMESSAGING-1896) MessagingClusterHealthMBean may block when stopping a node

by Yong Hao Gao (Created) (JIRA)

MessagingClusterHealthMBean may block when stopping a node ---------------------------------------------------------- Key: JBMESSAGING-1896 URL: https://issues.jboss.org/browse/JBMESSAGING-1896 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.8.SP3, 1.4.0.SP3.CP14 Reporter: Yong Hao Gao Assignee: Yong Hao Gao Fix For: 1.4.0.SP3.CP15, 1.4.8.SP4 When a node is shunned from the node but at the same time its DB is also disconnected, the MessagingClusterHealthMBean will shut down the node in the jgroups thread. Because the shutdown happens in the process of view change, it will block on the MessagingPostOffice.stopViewUpdate() method. I will wait for the flag updateInProcess forever because it will never get a chance to update the flag. See the stack trace: "Incoming-10,192.168.1.110:55200" prio=10 tid=0x00007f619c036800 nid=0x4b2e in Object.wait() [0x00007f618a24a000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000d94c55d8> (a java.lang.Object) at java.lang.Object.wait(Object.java:502) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.stopViewUpdate(MessagingPostOffice.java:852) - locked <0x00000000d94c55d8> (a java.lang.Object) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.stop(MessagingPostOffice.java:796) at org.jboss.messaging.core.jmx.MessagingPostOfficeService.stopService(MessagingPostOfficeService.java:554) at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:405) at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:281) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.jms.server.MessagingClusterHealthMBean.stopService(MessagingClusterHealthMBean.java:140) at org.jboss.jms.server.MessagingClusterHealthMBean.stopNodeOnDBFailure(MessagingClusterHealthMBean.java:107) - locked <0x00000000d731a520> (a org.jboss.jms.server.MessagingClusterHealthMBean) at org.jboss.jms.server.ServerPeer.stopJBMNodeForRecovery(ServerPeer.java:2115) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1748) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1568) at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:733) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776) at org.jgroups.JChannel.up(JChannel.java:1336) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:439) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:153) at org.jgroups.protocols.FRAG2.up(FRAG2.java:188) at org.jgroups.protocols.FC.up(FC.java:493) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:543) - locked <0x00000000d94b2c90> (a org.jgroups.Membership) at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:463) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:749) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) at org.jgroups.protocols.UNICAST.up(UNICAST.java:328) at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708) at org.jgroups.protocols.BARRIER.up(BARRIER.java:136) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) at org.jgroups.protocols.FD.up(FD.java:284) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:328) at org.jgroups.protocols.MERGE2.up(MERGE2.java:144) at org.jgroups.protocols.Discovery.up(Discovery.java:264) at org.jgroups.protocols.PING.up(PING.java:273) at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2319) at org.jgroups.protocols.TP.passMessageUp(TP.java:1253) at org.jgroups.protocols.TP.access$100(TP.java:50) at org.jgroups.protocols.TP$1.run(TP.java:1177) 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:636) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

5
4
0 / 0

[JBoss JIRA] (JBCL-180) Classcast Exception while deploying an ear file in jboss 5.1.0

by suresh kumar (Created) (JIRA)

Classcast Exception while deploying an ear file in jboss 5.1.0 -------------------------------------------------------------- Key: JBCL-180 URL: https://issues.jboss.org/browse/JBCL-180 Project: JBoss ClassLoader Issue Type: Bug Components: ClassLoader, MetaData Reporter: suresh kumar Assignee: Ales Justin Priority: Blocker When we tried to migrate our application from jboss-3.2.7 to jboss-5.1.0, we faced this issue.Basically in our application, we have an EAR file packaged with couple of WAR files and a SAR file along with META-INF directory. While deploying the EAR file under server\default\deploy directory, we are getting the below error.Our application do not useany EJB related stuffs. Basically,this error is thrown when we have an SAR file and WAR files packaged together in an EAR file. Caused by: java.lang.ClassCastException: org.jboss.metadata.ear.jboss.ServiceModuleMetaData cannot be cast to org.jboss.metadata.ear.spec.WebModuleMetaData at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:327) at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:97) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(Abstra ctSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer .java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) ... 30 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
1
0 / 0

[JBoss JIRA] (AS7-2141) Attribute socket-binding-port-offset for server-group cannot be set to 0

by Rostislav Svoboda (Created) (JIRA)

Attribute socket-binding-port-offset for server-group cannot be set to 0 ------------------------------------------------------------------------ Key: AS7-2141 URL: https://issues.jboss.org/browse/AS7-2141 Project: Application Server 7 Issue Type: Bug Components: CLI, Domain Management Affects Versions: 7.1.0.Alpha1 Reporter: Rostislav Svoboda Assignee: Brian Stansberry Fix For: 7.1.0.CR1 Issue met when invoking these operations in CLI: /server-group=main-server-group:write-attribute(name="socket-binding-port-offset", value=100) /host=master/server-config=server-one:restart /server-group=main-server-group:write-attribute(name="socket-binding-port-offset", value=0) { "outcome" => "failed", "failure-description" => {"domain-failure-description" => "0 is an invalid value for parameter socket-binding-port-offset. A minimum value of 1 is required"}, "rolled-back" => true } In standard distribution there is no port offset defined for /server-group=main-server-group. Tested with latest build from source codes pulled on 2011-10-18. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (AS7-1774) NPE in JndiView

by Heiko Braun (JIRA)

NPE in JndiView --------------- Key: AS7-1774 URL: https://issues.jboss.org/browse/AS7-1774 Project: Application Server 7 Issue Type: Bug Components: Console Reporter: Heiko Braun Assignee: David Bosschaert Fix For: 7.1.0.CR1 On the admin's console, when going on the naming view. It's a null point exception that I get on org.jboss.as.ee.subsystem.EEJndiViewExtension.handleModule(JndiViewExtensionContext, DeploymentUnit, ModelNode, ServiceRegistry) I avoid this, I added: if (moduleDescription == null) return; After this, the view is working and I can navigate in the JNDI view. I have no idea why moduleDescription was null, perhaps it's something wrong with my deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1080) XA Datasource w/o xa-properties swllows an exception

by Heiko Braun (JIRA)

XA Datasource w/o xa-properties swllows an exception ---------------------------------------------------- Key: AS7-1080 URL: https://issues.jboss.org/browse/AS7-1080 Project: Application Server 7 Issue Type: Bug Reporter: Heiko Braun Fix For: 7.1.0.Alpha1 ry to add an XA Datasource but don't add any XA properties. You will get the error below on the server. The problem is that the user doesn't see any error message at all. I assume that this is a known class of problem, but I mention here for bookkeeping purposes. 12:45:43,109 WARN [org.jboss.as.controller] (HttpManagementService-threads - 4) Operation ("add") failed - address: ([ ("subsystem" => "datasources"), ("xa-data-source" => "foo") ]): org.jboss.as.controller.OperationFailedException: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in o rg.jboss.jca.common.metadata.ds.XADataSourceImpl [ "Failed to create XaDataSource instance for [{ \"operation\" => \"add\", \"address\" => [ (\"subsystem\" => \"datasources\"), (\"xa-data-source\" => \"foo\") ], \"name\" => \"foo\", \"jndi-name\" => \"bar\", \"enabled\" => true, \"driver-name\" => \"h2\", \"driver-class-name\" => \"org.h2.Driver\", \"driver-major-version\" => 1, \"driver-minor-version\" => 2, \"pool-name\" => \"foo_Pool\", \"user-name\" => \"asdf\", \"password\" => \"asdf\", \"xa-data-source-properties\" => {} }] reason:IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.XADataSourceImpl" ] at org.jboss.as.connector.subsystems.datasources.XaDataSourceAdd.startConfigAndAddDependency(XaDataSourceAdd.java:64) at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:93) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (AS7-1310) Manage resource adapters through web console

by Heiko Braun (JIRA)

Manage resource adapters through web console -------------------------------------------- Key: AS7-1310 URL: https://issues.jboss.org/browse/AS7-1310 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.1.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (AS7-1872) Provide the ability to configure RA pools from the console

by Heiko Braun (JIRA)

Provide the ability to configure RA pools from the console ---------------------------------------------------------- Key: AS7-1872 URL: https://issues.jboss.org/browse/AS7-1872 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.1.0.Alpha1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2011