June 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING-969 - exposing temporary destinations via JMX

by sergeypk

I sort of don't understand how JBMESSAGING-969 is supposed to be used once it will be done. Do I really want to access a temporary queue via an ObjectName such as jboss.messaging:service=Queue,name=some-ugly-and-very-long-guid? How would I find out the queue name? Was there a forum thread related to this? None is referenced from JIRA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057605#4057605 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057605

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Message order receipt assumptions

by timfox

Currently JBM uses two JGroups channels: 1) A data channel for fast sending of unreliable messages across a network 2) A control channel for binding/unbinding queues, and various other "control" operations. Up til now we haven't required the ordering guarantee for 2) to be any better than FIFO (order of messages sent from a particular node is maintained). However, a new requirement has come up which, for a particular message only, we require each node to receive that message in the same order with respect to any view change messages on every node. Note this only applies to that message, for all other messages on the control channel they don't have to be in the same order with respect to view changes. So... I was looking for some kind of virtual synchrony type protocol I could use with JGroups. AFAICT JGroups supports a total ordering using a Singleton approach which should give us the ordering guarantee we need, but my worry is this might be a sledgehammer to crack a nut. Any comments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057585#4057585 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057585

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Grouping of messages with JMSXGroupId(JBMESSAGING-375)

by timfox

Thanks Stian- I think we should add an attribute on the server "enableMessageGrouping". And then just use the message grouping router by default. If you get your final changes together, someone will integrate it into TRUNK, then I shall add you to the contributors list. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057580#4057580 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057580

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-999 (Bridge should retry on startup)

by timfox

Yes, I think start() should return immediately and connection creation should occur on a different thread. Actually this already happens when connections failed so it should be a fairly simple matter of just ensuring that that same code kicks in. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057578#4057578 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057578

18 years, 9 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING-999 (Bridge should retry on startup)

by sergeypk

I've committed the code (a one-line change). Now the start() operation does not return until the bridge has actually established both connections. But I'm actually not sure if this is desired, maybe start() should return immediately and the bridge should work on establishing connections on its own in a separate thread? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057563#4057563 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057563

18 years, 9 months

1
0
0 / 0

[Design of JBoss Profiler] - JBoss Profiler Quick Start

by ScottDawson

Please consider adding a "Quick Start" guide to the JBoss Profiler documentation to help new users get up and running quickly. Here's my first draft based on JBoss Profiler 1.0.CR4 with JBoss App Server 4.0.5 and Java 1.5: Installation: 1) copy jboss-profiler-noAOP.sar to the JBoss AS deploy directory 2) put jbossInspector.dll in your PATH (Windows) or libjbossInspector.so in your LD_LIBRARY_PATH (Linux/Unix) 3) copy jboss-profiler.war to the JBoss AS deploy directory Configuration: 1) Add something like this to the JBoss JVM options: -XrunjbossInspector:/tmp/profiler,include=com.unisys,ignore=*,memory=false Make sure the output directory (/tmp/profiler in this example) exists. Usage: 1) In the jmx-console, use the jboss.profiler Native-profiler mbean to activate profiling 2) Exercise your application 3) In the jmx-console, use the jboss.profiler Native-profiler mbean to stop profiling (if you forget to do this, you will probably get a java.io.EOFException when you try to use the analyzer war) 4) Analyze results using the JBoss Profiler web app at localhost:8080/jboss-profiler Example analysis: a. Click on 'Runtime Profiler' b. Enter the output directory, for example, /tmp/profiler c. Check 'Stack on methods', uncheck other options and submit d. Click 'click here' e. Click the 'All Methods' link to get a view of time allocation among individual methods Regards, Scott Dawson Unisys View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057532#4057532 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057532

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Listener Notifications to happen asyncronously?

by bstansberry＠jboss.com

Thanks for the link Jason. That thread happened when was out and when I read it last Tue AM it didn't sink in. When we think about these notifications, we shouldn't assume people necessarily want to misbehave and call back into the cache. I used to have to make get calls into the cache to do what I needed, but that's no longer needed w/ the new API that provides the data. But, I still need dependable timing and dependable locking semantics. I'll be specific about AS use cases: 1) For EJB3 SFSB, I get nodePassivated/nodeActivated notfications. I get the target bean from the notification-provided Map and invoke any @PrePassivate/@PostActivate methods. This *must* be done synchronously, before the bean is serialized. (There's no tx involved here.) 2) For web sessions, notifications tell me that a session has been modified remotely. The session manager needs to know this, and the notification needs to arrive in a timely manner, with the WL on the cache nodes serving as a nice concurrency guard for the session. Getting the notifications at tx commit would be fine, as long as the WL is still held. #2 will likely someday be redesigned, but I'd prefer not to have to do that now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057517#4057517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057517

18 years, 9 months

1
0
0 / 0

[Design of JBoss Tools (dev)] - Re: JBoss IDE vs Red Hat Developer Studio....what is the dif

by max.andersen＠jboss.com

end of summer 2007 is the planned GA release View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057515#4057515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057515

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: Need to make enhacements to CacheListener API

by bstansberry＠jboss.com

The wiki page mentions "Merge pre and post phase". I need the current (CR2) timing. Specifically, I need the pre callback for nodePassivated. Merging to me implies "post". In general though, the annotation idea seems good. The interface approach has proven too fragile. And I know I've created a lot of little inner classes extending AbstractCacheListener just so I could implement one callback. That's pretty clunky when I think about it. It will be slower, since reflection is involved. We'll probably have to organize listeners by callback so we can quickly invoke on the relevant ones, rather than iterating through each listener for every callback to check if it is interested. I guess the addListener API just takes Object. Odd, but an alternative is to make CacheListener a marker interface. That's even more odd. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057514#4057514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057514

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

Sorry about the delay in replying - I was on vacation :-) "heiko.braun(a)jboss.com" wrote : We can defer creation of JAXBContext's to JBossWS factory. The SPI ships with a default FactoryLoader implementation that allows us to change the implementation through a /META-INF/services entry. | | IMO this would be the easiest. Another option would be indirect creation though the MC. Then the factory would become part of jbossws-beans.xml. How would we get the properties instance (which will be different per typeset for which the JAXBContext is being created) into this factories scope? "thomas.diesler(a)jboss.com" wrote : Why specifically do you need to interact with such low level detail as JAXB properties. A JAXWS client should not have to do that AFAIK. This forum post to the JAXB Forums should explain why we need it: http://forums.java.net/jive/thread.jspa?threadID=27591&tstart=0 The changes I'm talking about are not really low level from a JBossWS perspective. The JAXBContext class provides 2 factory methods for creating the JAXBContext, one which takes a properties set and one which does not. From a JBossWS perspective, we're just talking about being able to specify a property set. To see how I'm doing this at the minute, see the JBossWSAdapter class - search for references to JAXBContextCache. So at the moment I relying on a hack whereby I'm setting the JAXBContext properties (for the SOAP message being processed) via a Threadlocal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057367#4057367 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057367

18 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2007