Re: [JBoss-dev] JMS issues re: stopservice, jndi names
From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util?? Regards, Hiram David Jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util?? Regards, Hiram David Jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Sorry to follow up my own message, but I need another question answered. Note: In the previous message, I was incorrectly saying db/messaging, it's really db/jbossmq/file Is it possible to have queues named: companyA companyA/myqueue1 companyA/myqueue2 I'm changing (in anticipation that deep queues are valid), the file pm for queues. It currently just get's a list of all files in db/jbossmq/file/ Then attempts to restore the MessageLogs for each file in that list. When MessageLog attempts to restore, it just looks for a . in the name (ie: QUEUE.bob), and restores all messages files in that dir, if no . is there it assumes the file is a message log and attempts to restore it directly, which is why my stuff is failing, because it looks like QUEUE.companyA/myqueue1/* But the restoration code assumes myqueue1 is a file, and not a subdir (because no .) It seems to me, that a much easier fix is to not restore the queue on startup, but instead restore in when the DD is deployed. But I suppose there may be a need to restore a queue before it's actually defined? The auto-restored queues doesn't show up in the 8082 UI (BTW what's that called?). So I am not sure why the PM is creating an instance of MessageLog for them at startup. Am I just not getting it? -David On Tue, 27 Nov 2001, David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
The JMS spec has nothing to say about JNDI namespace conventions for administered objects, so add support for this. There is an assumption of a flat namespace under queue and topic that needs to be generalized. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Budworth [EMAIL PROTECTED] To: Hiram Chirino [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 27, 2001 12:55 PM Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.27 16:32:05 -0500 David Budworth wrote: Sorry to follow up my own message, but I need another question answered. Note: In the previous message, I was incorrectly saying db/messaging, it's really db/jbossmq/file Is it possible to have queues named: companyA companyA/myqueue1 companyA/myqueue2 I'm changing (in anticipation that deep queues are valid), the file pm for queues. It currently just get's a list of all files in db/jbossmq/file/ Then attempts to restore the MessageLogs for each file in that list. When MessageLog attempts to restore, it just looks for a . in the name (ie: QUEUE.bob), and restores all messages files in that dir, if no . is there it assumes the file is a message log and attempts to restore it directly, which is why my stuff is failing, because it looks like QUEUE.companyA/myqueue1/* But the restoration code assumes myqueue1 is a file, and not a subdir (because no .) It seems to me, that a much easier fix is to not restore the queue on startup, but instead restore in when the DD is deployed. But I suppose there may be a need to restore a queue before it's actually defined? The auto-restored queues doesn't show up in the 8082 UI (BTW what's that called?). So I am not sure why the PM is creating an instance of MessageLog for them at startup. Am I just not getting it? You need to read in all the info pertaining to a particular pm when the pm is started so you can figure out what to do with incomplete transactions. Is there some way you can improve the naming conventions to make your nested queue names work without modifying the rest of the startup code? david jencks -David On Tue, 27 Nov 2001, David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.27 17:21:31 -0500 David Budworth wrote: So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). Maybe you can make it work. I didn't see any way to, and I couldn't figure out any way to test it either. So I tried to change it as little as possible. You will definitely have to keep track of the recovered transaction info until all queues are restored: detecting this may me another trick. I thought it was way simpler to process it all at once when the pm started. Why is this causing you problems? I don't see the connection to the namespace issues. david jencks -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Nevermind, problem fixed. I just changed how it finds the directories on restoreTransactions(), and made it ignore them in MessageLog.restore() I'll commit after some testing. -David On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 17:21:31 -0500 David Budworth wrote: So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). Maybe you can make it work. I didn't see any way to, and I couldn't figure out any way to test it either. So I tried to change it as little as possible. You will definitely have to keep track of the recovered transaction info until all queues are restored: detecting this may me another trick. I thought it was way simpler to process it all at once when the pm started. Why is this causing you problems? I don't see the connection to the namespace issues. david jencks -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMS issues re: stopservice, jndi names
Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? David Jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Such utility methods already exists and since this is not specific to
services so it should not be placed into a service or deployer base class.
package org.jboss.naming;
public class Util
{
...
/** Bind val to name in ctx, and make sure that all intermediate
contexts exist
@param ctx, the parent JNDI Context under which value will be bound
@param name, the name relative to ctx where value will be bound
@param value, the value to bind.
*/
public static void bind(Context ctx, String name, Object value) throws
NamingException;
/** Bind val to name in ctx, and make sure that all intermediate
contexts exist
@param ctx, the parent JNDI Context under which value will be bound
@param name, the name relative to ctx where value will be bound
@param value, the value to bind.
*/
public static void bind(Context ctx, Name name, Object value) throws
NamingException;
/** Rebind val to name in ctx, and make sure that all intermediate
contexts exist
@param ctx, the parent JNDI Context under which value will be bound
@param name, the name relative to ctx where value will be bound
@param value, the value to bind.
*/
public static void rebind(Context ctx, String name, Object value) throws
NamingException;
/** Rebind val to name in ctx, and make sure that all intermediate
contexts exist
@param ctx, the parent JNDI Context under which value will be bound
@param name, the name relative to ctx where value will be bound
@param value, the value to bind.
*/
public static void rebind(Context ctx, Name name, Object value) throws
NamingException;
}
I'm not sure if this is by spec though. Are you not allowed to create a
heirarchy for the queue/topic names? If I create transient topics, I
can do it if I pre-create the subcontexts. So I know it 'works', I'm
just not sure it's legal.
Also, is there some helper code somewhere in jboss to create a JNDI tree
already? Or does everyone just roll there own with tokenizers or
something?
I feel like I've seen 10 or twenty implementations of this, but its
probably just 3 or 4;-) They are often in Deployers. Could we put one
version in either DeployerMBeanSupport or ServiceMBeanSupport?
David Jencks
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
