Hi Wickus-
Yes, since the version you are using the default remoting configuration has
changed.
I would strongly recommend using the remoting configuration that comes with JBM
1.4.0.SP3.
In particular, there is a known issue with JBoss Remoting control connection
pinging, which might cause
We aim to get a JBM 2.0 GA release out towards the end of the year, a beta in
the summer, and an alpha in four to six weeks time,
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4131047#4131047
Reply to the post :
Clearly the extra sem-colon is a bug.
But regarding the issue of not allowing JMSX properties to be set:
The JMS spec (1.1, section 3.5.8, table 3.3) makes it clear that the only JMSX
properties that can be set by the client are JMSXGroupID and JMSXGroupSeq.
So I think the current behaviour is
Also this is related to http://jira.jboss.org/jira/browse/JBMESSAGING-1185
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4131051#4131051
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4131051
First thing I would do is take MDBs out of the picture - try creating a vanilla
JMS consumer on each node.
The MDB layer buffers some messages - ready to send to it's local MDB instances
- which will prevent them from being available for other nodes.
Secondly, JBM (like pretty much any other
Have you tried with a more recent version of JBM?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4130353#4130353
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4130353
___
Hello Wickus-
Any chance you could try with 1.4.0.SP3 and remoting 2.2.2.SP4?
Several things have been fixed in remoting since the version you are using.
If you're using the supported EAP 4.3 configuration, you'll already be using
that.
Cheers
View the original post :
martin.wickus wrote : Precondition: JBM cluster consisting of two nodes
posting messages to a clustered queue. The JBM cluster is formed across JBoss
nodes.
|
| Step1. Start up a plain java process (configured with JBM client libraries
and patched JBoss Remoting lib) which looks up a
Also make sure you don't have other consumers on the nodes. Any local consumers
will always get the message if they are not busy.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4130049#4130049
Reply to the post :
Final thing to note:
In 95% of user deployments, message redistribution is NOT necessary.
Typically users deploy a homogeneous bank of MDBs (or other consumers) across
the cluster - the same ones on each node. Client producing connections are also
load balanced across the cluster. Since
I would double check again that you haven't changed any of the remoting
settings from those in the distribution.
If you are using service binding manager, ensure you have copied *exactly*
those settings from the ones in the distro.
View the original post :
There is also a simple distributed queue example in the distro that we
recommend you run (see install guide) - can you see if this works?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4130057#4130057
Reply to the post :
Right - this implies that distribution is not working for you - it works about
half the time, and about half the time the consumer will be created (randomly)
on the same node.
Almost certainly there's something wrong in your JGroups setup
View the original post :
BTW, can you please try with the preconfigured queues (i.e. do not change
ANYTHING from the example) from the distro - i.e. don't use your own queue.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4130078#4130078
Reply to the post :
Thanks, good catch :)
I have created a JIRA report:
http://jira.jboss.org/jira/browse/JBMESSAGING-1235
We'll get this fix into the next CP.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4130160#4130160
Reply to the post :
JBM currently only supports Java clients natively. Non Java native client
support is scheduled sometime after 2.0.
You may be able to use StompConnect though in the mean time.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4129963#4129963
Reply to the post :
Just use the standard JCA JMS resource adaptor - this is available in the same
VM:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossJMSRA
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4129965#4129965
Reply to the post :
Please can you be more specific about what you have done, and what you have
observed (step by step instructions).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4129959#4129959
Reply to the post :
kdeboer wrote :
| Can the destination be reconfigured as a resource reference in jboss.xml
deployment descriptor?
|
See my previous post.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4129961#4129961
Reply to the post :
I'm assuming you're trying to access JBM from a Servlet being running with the
version of JBoss Web that comes bundled with JBoss AS.
If you're not using that, I'd ask why you don't just use that!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4129966#4129966
kdeboer wrote : Thanks for the link. I was aware of this wiki page.
| But there is something unclear to me:
| If you have a handle to a remote connectionFactory, how can you get a
handle to a queue running in a remote server. Is this automatically done in the
correct JNDI namespace (the
You can't lose messages with DUPS_OK, but there is a possibility of duplicates
if the system fails and recovers.
As Andy says, you can then implement duplicate detection and effectively then
get once and only once delivery.
View the original post :
vc123 wrote :
|
| 1. I will, but we do not want DUPS ;)
|
|
Well you won't get reliable (once and only) delivery using AUTO_ACKNOWLEDGE
either.
AUTO_ACK = *at most once*
anonymous wrote :
| 3. Is producer flow control going to be implemented in JBM 2 ?
|
yes
View the
vc123 wrote : ataylor wrote :
| | I am not sure why the consumer falls behind so quickly. True, the
producer does not do much, but neither does the consumer, and yet it is about
30% slower than the producer which leads to the queue explosion.
| |
|
| Probably the other
Maybe this helps:
http://wiki.jboss.org/wiki/Wiki.jsp?page=HowDoIConfigureTheJMSResourceAdapterToUseARemoteConnectionFactory
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4129534#4129534
Reply to the post :
jimrigsbee wrote : I had some trouble resolving what client libraries I
needed to get my simple JMS sender program to work. I finally resolved that I
needed:trove
| | javassist
| | jbossall-client
| | jboss-aop-jdk50
| |
| |
Yes, that's what the user guide install section
Hypersonic has no transaction support, so should never be used other than very
simple demos.
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4128503#4128503
Reply to the post :
vc123 wrote : Hi,
|
| We are evaluating JBoss Messaging suitability for reliable delivery.
|
| I am not quite sure how reliable message delivery (PERSISTENT) is
implemented in JBoss Messaging. Assuming a JDBC persistence manager, does the
AUTO_ACK mode result in a JDBC commit after
For persistent messages, you are fundamentally limited by the speed of your
database.
So your persistent message throughput will entirely depend on how your Oracle
box is set-up tuned etc. Oracle is very tunable however.
View the original post :
Yes beware that RHM/QPid has very poor JMS support.
The current AMQP spec is lacking in many areas and not currently rich enough to
support full JMS semantics (e.g. it lacks any concept of filters/selectors).
QPid added proprietary hacks over and above the AMQP spec in order to get
their JMS
[Moved from design forum to user forum]
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4128053#4128053
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4128053
___
jboss-user mailing
Posting on the developer forum, cross posting, and using URGENT in the titles
of threads is NOT a good way to get us to respond!!
I am locking this thread
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4128055#4128055
Reply to the post :
Posting on the developer forum, cross posting, off topic posts, and using
URGENT in the titles of threads is NOT a good way to get us to respond!!
Please observe basic forum etiquette in future before making posts or you will
be ignore or your posts deleted.
I am now locking this thread, you
| version3.2.3/version
|
You're taking jboss-all-client from JBoss 3.2.3??
The classpath you quote should certainly work, you're probably just pulling in
wrong versions of those files though.
To verify this, take Maven out of the picture and _manually_ get those jars
from the distro.
They should be there.
If not it looks like the product team ommitted them :(
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4127880#4127880
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4127880
ydzsidemiik wrote :
| During my testing, I was surprised to find that priorities set on JMS
message objects (javax.jms.Message.setJMSPriority(int)) seem to be getting
ignored. The high priority messages come out of the queue with their priority
set to 4, which would explain why they are not
I haven't run your code but I had a quick look at it. A couple of observations
1) As already mentioned. JMSPriority set on a message is ignored - you need to
set it on the producer (as per JMS spec)
2) JBM (and pretty much every other messaging system) buffers messages on the
client side.
So
I agree that although your application usage of temporary queues was an
anti-pattern, it shouldn't leak threads as long as you were closing the
connection.
Can you create a JIRA with a small program that demonstrates this issue and we
will investigate further?
Also can you first verify you're
mr.colin.daly wrote :
| for the record setting Clustered to false fixes that last problem...
|
Yes, if you want clustering you need to make sure you are in the all
configuration, I suspect you are using a non clustered configuration like
default.
View the original post :
In most cases, allowing selectors on a JMS queue is an anti-pattern since it
can cause the queue to be scanned frequently - i.e. give poor performance.
Also JMS selectors only work on the *local* queue - i.e. each clustered queue
is made up of n local partial queues - one on each node. If your
[Moved from the design forum]
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4127004#4127004
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4127004
___
jboss-user mailing list
Can you explain your topology in more detail - i.e., where are the clients that
put messages on the queue and where are the clients that remove messages from
the queue? (It's important to know what node they're on).
Also can you post your message consumer code? Thanks
View the original post :
Bear in mind I said 2.0 series. I.e. 2.0 probably won't have support for
other language clients (depending on how much time we have) - more likely 2.1 :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4126483#4126483
Reply to the post :
So you have a clustered response queue, and, say two consumers on it on
different nodes
A response message gets posted to the queue. Clearly the response message is
destined for a specific consumer, but if you have two consumers on the queue,
you can' be sure it gets to the right consumer
I would have a look in your code to see where you are creating temporary
queues, and make sure you are deleting them when you're finished.
Also it's worth taking a look in JNDI (use jmx-console) to see if there are a
lot of temp queues hanging around.
View the original post :
BTW I would avoid creating a new temp rely queue for every message you send.
This is likely to adversely affect performance.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4126698#4126698
Reply to the post :
ydzsidemiik wrote : Just to clarify, you are talking about a stand alone,
J2SE client connecting to JBM from outside the container, correct? This is my
understanding of 'no EJB', as I assume you are not talking about writing MBeans.
|
| .
It can be inside or outside the container, it
ydzsidemiik wrote : I am trying to test the pure JMS approach, but I am
seeing this error:
|
| javax.jms.IllegalStateException: This method is not applicable inside the
application server. See the J2EE spec, e.g. J2EE1.4 Section 6.6
| at
Sorry - I don't know anything about Maven, we don't use it.
JBM should work out of the box with JBosss 5 beta 3 - it's the default JMS
provider.
What classpath are you using that doesn't work?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125845#4125845
Please can you post (or mail me) a complete thread dump of the server when this
problem occurs? (killall -3 java)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125846#4125846
Reply to the post :
JMSUserManager is really an artifact from JBoss MQ days. It maintains a mapping
of user-preconfigured client id.
If there is an entry for a user, then when the user creates a connection, the
server will preconfigure that connection with that client id.
If you don't want that functionality you
http://jira.jboss.org/jira/browse/JBMESSAGING-1228
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125849#4125849
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4125849
___
Can you try using pure JMS (i.e. no MDBs) and see if the problem still occurs?
The MDB layer does some buffering so this may be related to the issue.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125848#4125848
Reply to the post :
We don't currently support non Java clients directly, but aim to do this for
the JBM 2 series.
However I believe StompConnect works with JBM
http://stomp.codehaus.org/StompConnect
And has many clients for .NET and other lanugages.
I personally haven't used this so can't vouch for it, but
thangle wrote : I have some questions relating this topic:
| 1. How many Queues can we safely create dynamically under JBoss 4.0.3? Is
it a recommended way?
JBoss 4.0.3 doesn't use JBossMessaging, it uses JBoss MQ. Please post in the
JBoss MQ forum, this the JBoss Messaging forum :)
View the
seattle.golfer wrote : any chance some of these features can/will be
backported to 1.4.x?
|
This is very unlikely - we don't really have the resources for that and it
would involve deep changes.
anonymous wrote :
| Also, in your opinion, is what's in source stable enough to start
bodrin wrote : It is strange that the messaging is using some configuration
inside $JBOSS_HOME/docs/examples.
|
Don't blame messaging! It is using the config from there because you (or
someone else on your side) configured it to use that. Do a search in the wiki
for ServiceBindingManager to
seattle.golfer wrote :
| I've been away from JBoss for about 4+ years (working in Weblogic), and
am finally coming back home.
|
Glad to hear it! :)
anonymous wrote :
| I'm trying to get a better handle on JBoss Messaging's clustering
capabilities. They way I read the
File based persistence is already done in TRUNK too
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125040#4125040
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4125040
___
http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.SP3/html/configuration.html#conf.serverpeer.attributes.suckerpassword
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4125264#4125264
Reply to the post :
Sorry you're running 1.4.1, it's:
http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.1.Beta1/html/configuration.html#conf.securityMetadataStore.attributes.suckerpassword
View the original post :
Can you first with a more recent version and see if the problem is still there?
JBM 1.4.0.SP3 or 1.4.1 with JBossRemoting 2.2.2.SP4 ?
If problem re-occurs please post a simple test case or simple instructions on
how to replicate and someone will take a look.
View the original post :
bodrin wrote : Ok. I tried to setup jboss-messaging-1.4.0.SP3 on
jboss-4.2.2.GA with jboss-remoting-2.2.2.SP4.
|
| I have done all the steps described in [4.1.1. Automated Installation] for
clustered installation with two nodes.
|
| When starting there is a problem with the remoting
If you're using old service binding manager configuration with invalid remoting
configuration with 1.3.0 this could explain your timeout issues with that...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4124864#4124864
Reply to the post :
[Moved from JBoss Messaging forum where it was mis-posted]
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4124869#4124869
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4124869
___
JBoss Messaging 1.40/1.4.1 is tested against JGroups 2.4.1.SP3 which is the
version of JG in the AS 4.2/4.3
We simply don't know if it will work with other versions of JG since it's not a
supported/tested configuration.
For AS 5, version JG 2.6 is used, so for this we will upgrade our
Several stack config settings have been deprecated in 2.6, which is why JGroups
is producing those warnings.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4123973#4123973
Reply to the post :
The point with non persistent messages, is they are not persisted, == they do
not survive failure.
Users use non persistent messages when they want higher performance but they
can cope with message loss.
If we had to persist non persistent messages too, that would kind of defeat the
purpose
Thanks for the report. :)
We'll get in fixed in the next release
http://jira.jboss.org/jira/browse/JBMESSAGING-1224
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4124039#4124039
Reply to the post :
kemp40 wrote :
| Btw, wouldn't be a really cool idea to replicate non-persistent messages
among active nodes to gain performance, it's really unlikely to have all nodes
crush ... ;)
|
|
Hello kemp,
Martin's comment was not correct, JBoss Mesaging *does* cluster non persistent
JBM will use the JGroups multiplexor in JBAS 5, but for JBAS 4.x we don't test
with the multiplexor, due to stability issues with it.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4121826#4121826
Reply to the post :
Tested/supported configuation of JBM in AS 4.2/4.3 is JGroups 2.4.1.SP3 with no
multiplexor.
Any other configuration you may or may not get to work, but we just don't know
- it's not a tested/supported version/configuration.
View the original post :
Also JG 2.5 or later is specifically known not to work in some cases with JBM
since it uses concurrent event queues which is new in 2.5.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4121829#4121829
Reply to the post :
nbakizada wrote :
|
| I'm having trouble understanding if the 2 nodes in a cluster act as some
sort of primary/secondary, or if they're both equal primaries. In the event of
a basic failover (one of the 2 appservers goes down), things failover to the
other just fine. But what happens if,
nbakizada wrote : The second oddity I noticed is this:
|
| Failover will occur cleanly if I kill -9 one of the 2 nodes' process.
|
| On the other hand, doing a graceful shutdown of the appserver on a given
node will NOT trigger failover. Any messages that were held on that given queue
Ok, you just described the HA singleton.
JBM supports this mode too, as mentioned before:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBMHASingleton
HTH
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4119981#4119981
Reply to the post :
Martin-
It might be worth asking the EJB3 guys to comment - they may have more insight.
One other thing you could do: In the 10 seconds before the timeout occurs,
could you get a fully Java thread dump (killall -3 java) and post it here?
View the original post :
bodrin wrote : OK, I see..
|
| The bad thing is that :
|
| ...
| When running this way you will lose other benefits of JBoss Messaging like
automatic failover and distributed destinations.
|
|
Well distributed destinations are meaningless anyway if you only have one
active
Could you post a simple sample program or test that exhibits the problem and
one of the team will take a look?
Thanks.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4119326#4119326
Reply to the post :
Bodrin-
I am trying to understand why you only want one node in the cluster to be
active at any one time?
Why not let your clients connect to any node, then you won't have these issues.
Maybe I don't understand your motivations for doing this...
View the original post :
There is no automatic creation of queues.
You need to ensure all queues you want to use are deployed before you use them.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4119371#4119371
Reply to the post :
bodrin wrote : I want to setup something like a master-slave cluster - all
jms clients (external) using only the master node and switch to the slave only
if the master is down.
If you want a JBoss MQ style approach where only one node is active at any one
time, you can deploy JBM as a HA
bodrin wrote :
|
| Don't you think that when I configure the ClusterConnectionFactory to not
load-balance it should use only the local node - the one to which I have a
connecttion already?
|
|
if you set supportsLoadBalancing to false on the ConnectionFactory then all
connections
bodrin wrote :
| Can you tell me where can I find this FAQ of how to configure JBM as a
ha-singleton?
With all the other FAQs on the wiki page ;)
I'll leave it as an exercise for you to find the JBoss Messaging wiki page...
View the original post :
bodrin wrote :
| Anyway, I can not undestand the behaviour of the current JBM. I'm
connecting to the master node (ha-jndi) and I have disabled the load balancing
of the ClusteredConnectionFactory and sometimes I get
| Assertion failed, 0 == 0
| sometimes
| Assertion failed, 1 == 1
|
Also if you give some kind of description of what your app does, does it use
other products (e.g. Spring), that would be good.
You seem to be opening and closing a lot of sessions.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4118226#4118226
Reply to the
Another observation.
In your helper class there's no need to explicitly close the session in your
finally block.
Closing the connection will automatically ensure the session is closed (or
returned to the pool).
| finally
| {
|
| try
It would be good if you could provide full allocation traces.
I don't know what profiler you are using, but I believe that JProfiler by
default only shows a certain depth, this is configurable.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4118428#4118428
This doesn't look right to me.
The only time that creating a connection, creating a session, doing something,
then closing them is not an antipattern, is when you are using a JMS JCA
resource adaptor.
This is because when using a resource adaptor, when you call createConnection()
it doesn't
Personally I try and discourage people from relying on resource adaptor caching
and using the ejb-style create connection, create session, do something,
close connection approach, since I believe this encourages poor JMS habits.
One thing to note is the JMS resource adapter only caches JMS
Not related to you case, but creating consumers for each action is exactly what
the Spring JMS template does, and is one reason why we can't recommend it.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4118433#4118433
Reply to the post :
Does this occur with the latest version of JBM? (1.4.0.SP3)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4117937#4117937
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4117937
___
assaf49 wrote : Hi Tim, we are not using a clustered connection.
| However, we read in Jboss documentation (see
http://docs.jboss.org/jbossas/javadoc/4.0.3SP1/j2ee/javax/jms/Connection.html)
| that a JMS provider should attempt to resolve connection problems itself
before it notifies the
assaf49 wrote :
| However, whilst connected, we would like our Listeners to be notified of
gaps in the order. In other words we would like JBM to tell us when some kind
of connection problem caused messages to be lost.
|
That can't happen, as long as the subscription is alive, there will
Hello Assaf, I am still having trouble understanding your scenario:
assaf49 wrote :
|
| Scenario Clarified:
| 1) Producer sends Message A.
| 2) BEFORE Message A is recieved, some Connection failure occurs on the
Listeners side. Note that the client does NOT crash, it's just a 'small'
I just added a FAQ on this:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessaging
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4116972#4116972
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4116972
JBM does not rely on the database to provide XA functionality, so should not be
used with an XA datasource.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4116970#4116970
Reply to the post :
A Topic is JMS mechanism for publish-subscribe messaging.
This basically means that multiple subscribers can subscribe to a particular
topic (e,g, a news feed), and _all_ the subscribers will receive messages
posted to that topic.
JMS also supports what is known as point to point messaging
Ok I think I understand what you are doing now :)
JBM does support clustered durable subscriptions.
If you had multiple MDBs on different nodes of the cluster with the same client
id and durable subscription name, then JBM will ensure that only one of them
will get the message.
This allows
Could you try upgrading to 1.4.0.SP3?
Also, on mysql, if you go to a mysql console and type show innodb status
http://dev.mysql.com/doc/refman/5.0/en/innodb-monitor.html
It will tell you what's causing the deadlocks.
Based on that you may be able to add some indexes to prevent the deadlock.
601 - 700 of 1586 matches
Mail list logo
