October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-998) Impelment security for temporary destinations

by Sergey Koshcheyev (JIRA)

Impelment security for temporary destinations --------------------------------------------- Key: JBMESSAGING-998 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-998 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Security Reporter: Sergey Koshcheyev Assigned To: Tim Fox There should probably be some attribute on the ConnectionFactory to set permissions required to use temporary destinations. See the forum thread for discussion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-784) Add Active/Passive deployment feature for JBoss Messaging in 2 node cluster (Need HA part and not Clustering part)

by Rohit Chowdhary (JIRA)

Add Active/Passive deployment feature for JBoss Messaging in 2 node cluster (Need HA part and not Clustering part) ------------------------------------------------------------------------------------------------------------------ Key: JBMESSAGING-784 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-784 Project: JBoss Messaging Issue Type: Task Components: JMS Clustering Affects Versions: 1.2.1 Reporter: Rohit Chowdhary Assigned To: Ovidiu Feodorov Need to be able to deploy JBoss Messaging nodes in a HA configuration, but not load-balanced. Such that only one node is actively serving all the requests, if the current active node goes down, then the passive node picks up the load. Reason would be: To use the available h/w resources at best. We have one dedicated physical server for running JBoss msg. Another physical server that hosts existing JBoss instance running some application. We want to use this second server running a passive JBossMsg instance. So in case when the dedicated JBossMsg goes down, then the second shared server can take the load temporarily automatically, till we bring back the dedicated up again. Other reason would be that we bring down the dedicated JBossMsg server for OS level patching, essentially minimizing the app downtime and increase availablity. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-838) Test scenario where no failover has occurred on server side...

by Tim Fox (JIRA)

Test scenario where no failover has occurred on server side... -------------------------------------------------------------- Key: JBMESSAGING-838 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-838 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta2 Reporter: Tim Fox Fix For: 1.2.0.GA When a client thinks the server has failed e.g. the netwrk between client--server temporarily fails but the network between server--server is ok, the server will return -1 to say no failover is occurring or times out then the client will retry the orginal node after a pause. The pause needs to be made configurable and a test devised to test this situation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

3
11
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1081) Allow configuration of distribution policy for queues with multiple consumers

by Julian Scheid (JIRA)

Allow configuration of distribution policy for queues with multiple consumers ----------------------------------------------------------------------------- Key: JBMESSAGING-1081 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1081 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Affects Versions: 1.4.0 CR3 Reporter: Julian Scheid Assigned To: Tim Fox Priority: Minor The distribution policy for queues is currently hardwired to RoundRobinDistributor (in MessagingQueue.java) like this: localDistributor = new DistributorWrapper(new RoundRobinDistributor()); remoteDistributor = new DistributorWrapper(new RoundRobinDistributor()); distributor = new ClusterRoundRobinDistributor(localDistributor, remoteDistributor); This is a good default for when multiple clients are consuming a queue for purposes of load balancing. However, when there are multiple consumers for purposes of fail-over it can be desirable to use the FirstReceiverDistributor policy instead so that a second consumer only gets messages when the first consumer fails. (I am aware that this is simplifying matters a bit, FirstReceiverDistributor makes no such guarantees.) This policy can currently only be changed by patching the source code and recompiling. It would be great if it would be possible to configure the distribution policy in a configuration file instead, ideally on a per-queue basis in destinations-service.xml. This would ideally allow specifying arbitrary class names so that it's possible to install custom distributors. All of this would obviously be useful for topics as well once JBMESSAGING-377 is implemented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1049) Exceptions in logs after clustering test run

by Tim Fox (JIRA)

Exceptions in logs after clustering test run -------------------------------------------- Key: JBMESSAGING-1049 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1049 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.GA After running clustering tests, several exceptions are found in the logs. These seem innocuous since the test suite passes but we should investigate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-963) Find a better place to put config files

by Tim Fox (JIRA)

Find a better place to put config files --------------------------------------- Key: JBMESSAGING-963 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-963 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Fix For: 1.2.0.SP2 Currently config files in the source tree are store in source/etc/server/default/deploy/... This seems unintuitive and somewhat clunky. Find a better more intuitive place to put them and update scripts accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-958) Ability to replay queues

by Tim Fox (JIRA)

Ability to replay queues ------------------------ Key: JBMESSAGING-958 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-958 Project: JBoss Messaging Issue Type: Feature Request Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta 1 It would be good to have an ability to "replay" queues. I.e. when messages are acked, they don't necessarily get removed from the queue, instead a pointer on the queue just moves to the next element. This would allow recovery scenarios where the queue can be replayed, by resetting the pointer and redelivering messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-742) Message.getJMSDestination could be null on redeployment of a queue

by Clebert Suconic (JIRA)

Message.getJMSDestination could be null on redeployment of a queue ------------------------------------------------------------------ Key: JBMESSAGING-742 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-742 Project: JBoss Messaging Issue Type: Support Patch Affects Versions: 1.0.1.SP2 Reporter: Clebert Suconic Assigned To: Clebert Suconic Fix For: 1.0.2.CR1, 1.0.2.GA, 1.0.1.SP2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

3
27
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1050) Replace usage of oswego concurrent with java.util.concurrent

by Tim Fox (JIRA)

Replace usage of oswego concurrent with java.util.concurrent ------------------------------------------------------------ Key: JBMESSAGING-1050 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1050 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta 1 Now we are Java 5 or later only, we should get rid of all oswego concurrent usage and use java.util.concurrent instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1075) MaxSize attribute being set causes a NullPointerException

by Jay Howell (JIRA)

MaxSize attribute being set causes a NullPointerException --------------------------------------------------------- Key: JBMESSAGING-1075 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1075 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.CR2 Reporter: Jay Howell Assigned To: Tim Fox When the MaxSize is set, a NullPointerException is thrown. In the container, Max size is set in the ManagedDestination before the server peer is set in the managed destination. The server peer is set in the destination when start() is called in DestinationServiceSupport. Code in the Managed Destination... public void setMaxSize(int maxSize) throws Exception { Condition cond = new JMSCondition(isQueue(), name); PostOffice postOffice = serverPeer.getPostOfficeInstance(); Collection subs = postOffice.getQueuesForCondition(cond, true); Iterator iter = subs.iterator(); while (iter.hasNext()) { Queue queue = (Queue)iter.next(); queue.setMaxSize(maxSize); } this.maxSize = maxSize; } Code in the DestinationServiceSupport... public synchronized void startService() throws Exception { super.startService(); try { serverPeer = (ServerPeer)server.getAttribute(serverPeerObjectName, "Instance"); destination.setServerPeer(serverPeer); We shouldn't be putting logic like this in our getters and setters. In a pojo Object factory pattern, where we don't have total control over the creation and setting of properties, we should stay away from putting these in our setters. For instance, this function requires that start be called to set the peer before setting the property. We should move the MaxSize property back to a regular property and move this logic into another function called by the start() of the Destination. In order to reproduce, you only need to put a MaxSize argument in the destination. ex. <mbean code="org.jboss.jms.server.destination.TopicService" name="jboss.messaging.destination:service=Topic,name=testTopic" xmbean-dd="xmdesc/Topic-xmbean.xml"> <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends> <depends>jboss.messaging:service=PostOffice</depends> <attribute name="SecurityConfig"> <security> <role name="guest" read="true" write="true"/> <role name="publisher" read="true" write="true" create="false"/> <role name="durpublisher" read="true" write="true" create="true"/> </security> </attribute> <attribute name="MaxSize">100000</attribute> </mbean> You then get the exception... 13:09:00,190 INFO [ServiceConfigurator] Problem configuring service jboss.messaging.destination:service=Topic,name=testTopic org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute@2110fc on mbean jboss.messaging.destination:service=Topic,name=testTopic; - nested throwable: (java.lang.NullPointerException) at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:698) at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:332) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:460) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171) at org.jboss.system.ServiceController.install(ServiceController.java:226) 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.install(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) 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 $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.GeneratedMethodAccessor3.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.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.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at sun.reflect.GeneratedMethodAccessor9.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.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.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) 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 $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at org.jboss.jms.server.destination.ManagedDestination.setMaxSize(ManagedDestination.java:280) at org.jboss.jms.server.destination.DestinationServiceSupport.setMaxSize(DestinationServiceSupport.java:250) 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.AttributeDispatcher.invoke(AttributeDispatcher.java:136) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:103) at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461) at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:608) at org.jboss.system.ServiceConfigurator.setAttribute(ServiceConfigurator.java:694) ... 85 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 7 months

2
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2007