Brian,
Now updated. Many thanks for your feedback.
By the way, using CacheManagerLocator 'tastes' decidely old-fashioned. Are
there any plans for JBoss Cache/Infinispan to support something like a @Cache
injection annotation for member variables? Something like:
@Cache(name='sfsb-cache')
|
So after my own few hours of headaches, I did my community bit and blogged what
I worked out...
http://kennardconsulting.blogspot.com/2009/12/newbies-guide-to-jboss-cache.html
Can somebody please check and make sure the information I am giving out is
correct, lest it end up making it worse for
A tip for those who come this way after us: we found a large part of the
problem was that the cluster nodes rely on being in constant communication.
If one of them is under high load (say, running some reports or something) its
CPU usage may be so high it does not respond to the cluster ping
Thanks Howard. I will keep an eye out for 1.4.6
Richard.
P.S. Did anyone get a chance to look at the log I posted to
https://jira.jboss.org/jira/browse/JBMESSAGING-1706? I think I may have found
the source of this tricky problem (ie. ConnectionStopRequest.serverInvoke)
View the original post
Hi guys,
Are there special considerations involved in upgrading JBoss 5.1.0 to use the
new JBoss Messaging 1.4.5.GA? I'm keen to be updated on the latest bugfixes.
I tried just copying the jboss-messaging.jar into JBoss, but now none of my
queues are recognised:
Guys,
We are seeing these warnings on our cluster nodes sometimes after a redeploy.
The primary cluster node stays up,
but the other 2 (we have 3) die and keep saying this.
2009-10-01 20:04:34,302 main WARN [org.jgroups.protocols.pbcast.GMS]
join(192.168.1.2:37802) sent to 192.168.1.1:52187
FAQ updated. Please review.
Regards,
Richard.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4242496#4242496
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4242496
___
jboss-user
Hi guys,
I'm having a hard time finding good documentation on
javax.transaction.HeuristicMixedException as it relates to JBoss Messaging.
JBoss Messaging seems to throw this exception intermittently while processing
large volumes of messages in a batch (say, 2000 messages over 3 cluster
Howard,
Wow. I swear you guys reply faster than any support forum I have ever used.
Thank you!
No, I'm afraid the Exception I posted is the entire thing. I assume it's JBoss
Messaging related because it comes about at the end of the JmsServerSession,
but if this question is better posted
Hi guys,
The JBoss Messaging guys suggested I post here (original thread here
http://www.jboss.org/index.html?module=bbop=viewtopicp=4241134#4241134).
I'm having a hard time finding good documentation on
javax.transaction.HeuristicMixedException. JBoss Messaging (and the old JBoss
MQ) seems
Tim,
Thanks. I have posted a message on the JCA forum.
Please note I may not be the only one seeing this. This JIRA seems to indicate
they see it intermittently too:
https://jira.jboss.org/jira/browse/JBESB-2484
It says JBoss Messaging sometimes causes a HeuristicMixedException to be
raised
Clebert,
Thanks for your input. I am fine to manually failover in my producer, as I
control that code.
However the problem I'm having is that, upon restarting a cluster node, the
MDBs do not 'wake up' and start consuming messages from the HA queue. The code
to connect the MDBs is controlled
gaohoward,
I would gladly rework and update the Wiki FAQ for you if you can furnish me
with a solution :)
Regards,
Richard.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4240921#4240921
Reply to the post :
gaohoward,
Awesome. You are a legend. Look forward to hearing how you go. If it helps:
1. I made the changes described in the Wiki, then copied the 'all' folder to a
new folder (I called it 'cluster2') and started a second instance of JBoss
using 'run -c cluster2
Howard,
Hmmm. From watching my logs, I think the reason the MDBs aren't 'waking up'
upon bouncing a node is because JBoss Messaging is still creating 3 local
queues, not one HA singleton one.
This, despite the fact that destinations-service.xml is under
deploy-hasingleton. Do I need to do
Tim,
Thanks for helping out.
If I understand correctly, JBM 1.x load-balances at distribution time, not
consumption time. In my case, I am sending 1000 messages to the queue in one
initial batch.
I see an initial flurry while all 3 of my consumers consume messages, then the
fastest one stops
Tim,
What you say is very interesting. Could you please elaborate on what you mean
when you say:
The local queue will first attempt to send messages to the local queue
until it determines it is busy
Do you mean the 'local queue will send messages to the prefetch buffer'?
If the processing
Tim:
Brilliant. I tried setting PrefetchSize to 1 and the 3 nodes are now consuming
messages evenly. This also explains why I thought there were still 3 local
queues even though I had defined the queue in deploy-hasingleton: there were
not 3 local queues, just 3 prefetch buffers.
Thanks so
gaohoward,
Thanks as always for your help. I don't think what you suggest is going to work
because:
1. As soon as new messages get delivered to its local queue, it will stop
sucking from other nodes. This is fine but it will mess up the delivery order
of messages
2. If I turn on 'strict
gaohoward,
Please, please - I am begging you!
I have spent several days on this and one of the main problems is that in all
of the documentation and forum postings members of one team keep referring
people to another team, who refer people to another team etc.
I understand different people
Having just upgraded from JBoss 4.2.3.GA (which used JBoss MQ I believe) to
JBoss 5.1.0.GA (which uses JBoss Messaging I believe), I am a bit confused as
to how the clustered JMS works.
I tried using /ClusteredConnectionFactory, and it seems to work, but its
behaviour seems to be clustered
Perhaps I should open a JIRA for this?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4239663#4239663
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4239663
___
jboss-user mailing
Opened: https://jira.jboss.org/jira/browse/JBMESSAGING-1667.
Thanks,
Richard.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4239884#4239884
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4239884
There's some code in
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple that says...
// keep a record of why we are rolling back i.e. who called us first, it's a
useful debug aid.
| if(_rollbackOnlyCallerStacktrace == null)
| {
|_rollbackOnlyCallerStacktrace = new
Tim,
I'm happy to add a feature request if this is outside spec.
Before I do, can I ask you to double check the spec because this did work in
JBoss 4.2.3.GA and JBoss MQ?
Regards,
Richard.
P.S. Using JNDIName doesn't really work, because the queue name itself is not
heirachical, so you can
gaohoward,
Thanks for the tip. Is there no internal JBoss Messaging requirement that queue
names (not JNDINames) be unique?
For example, can I do...
mbean ... name=emails
|attribute name=JNDINameapp1/emails/attribute
| /mbean
|
| mbean ... name=emails
|attribute
jaikiran,
My apologies: it does work after all. It is a little confusing because the
opening trace makes it look like it has forgotten the arg:
C:\out-of-the-box\jboss-5.1.0.GAbin\run -Djboss.service.binding.set=ports-01
| Calling C:\out-of-the-box\jboss-5.1.0.GA\bin\run.conf.bat
|
jaikiran,
Your example uses the attribute JNDIname, but the queue name is still just
DLQ...
mbean code=org.jboss.jms.server.destination.QueueService
| name=jboss.messaging.destination:service=Queue,name=DLQ
...it is the queue name I wanted to be heirarchical. I thought by putting it
under a
jaikiran,
Thank you for staying with me. Your patience is most appreciated.
Unfortunately what you suggested did not work.
Even if it had, I'm not sure it would have been a good idea because jboss.xml
is app-specific whereas destinations-service.xml is 'JBoss wide': if I declare
a
Doesn't the syntax in JBoss 5's bindings-jboss-beans.xml...
parameter${jboss.service.binding.set:ports-default}/parameter
...allow changing the ports without hand-editing the bindings.xml file (as
recommended by this Wiki http://www.jboss.org/community/wiki/ConfigurePorts)?
It would be really
Okay cool. I've opened a JIRA: https://jira.jboss.org/jira/browse/JBMETA-208
Thanks for all your time and help.
Richard.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4238063#4238063
Reply to the post :
The JBoss Messaging guys (you have them to blame for this :) suggested I refer
this issue to you.
In JBoss 4.2.3.GA, I was able to declare my queues like this...
mbean code=org.jboss.mq.server.jmx.Queue
|name=jboss.mq.destination:service=Queue,name=my-app/imports1
|...
| /mbean
Thanks Tim.
I have jumped this discussion across to:
http://www.jboss.org/index.html?module=bbop=viewtopicp=4238065#4238065
Regards,
Richard.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4238066#4238066
Reply to the post :
Hi all,
In JBoss 4.2.3, I used to be able to do...
new InitialContext().lookup( ear-name/ejb-name/local )
...and it worked great, even from servlet filters. But in 5.1.0.GA, I can find
no such mapping, even though the logs say the beans are all deployed.
I see a lot of references in the
Hi all,
In JBoss 4.2.3, I used to be able to do...
mbean code=org.jboss.mq.server.jmx.Queue
|name=jboss.mq.destination:service=Queue,name=app/imports1
|...
| /mbean
...and it worked great, but in JBoss 5.1.0.GA, I'm being told 'app' is not
bound. I can get it working if I do...
jaikiran,
Thank you for your fast reply. Here is a snippet of the console output (the
actual output is very long, as you can imagine). Let us say I am after the bean
'DocumentBean'. Here is everything from the console that mentions DocumentBean:
| ...lots of output...
| 2009-06-15
jaikiran,
Thanks again for being so helpful. Again there is rather a lot of code
involved. I will try to post the relevant bits:
package com.avant.ss.ejb.session;
|
| import java.io.File;
|
| import javax.ejb.Stateful;
|
| import com.avant.ss.ejb.entity.Document;
| import
jaikiran,
Apologies. My deployment is exploded, so avant-ss-ejb.jar is a folder at:
N:\jboss-5.1.0.GA\server\all\deploy\avant-ss-app.ear\avant-ss-ejb.jar\
No, avant-ss-ejb.jar is not mentioned in any MANIFEST.MF. Only in
application.xml:
?xml version=1.0 encoding=UTF-8?
| application
gaohoward,
Thank you for your quick reply.
Unfortunately using JNDIName gives the same error ('app' not bound). It's
probably fair to say that app isn't bound, but I was kind of hoping JBoss
Messaging would create it automatically (like JBoss MQ did).
Regards,
Richard.
View the original
It is not present anywhere else, or reference in any MANIFEST files, sorry.
But note it is not a JAR file either: it is an exploded folder named '.jar'.
This is okay in 4.2.3.GA - is it still okay in 5.1.0.GA?
View the original post :
destinations-service.xml:
?xml version=1.0 encoding=UTF-8?
|
| !--
| Messaging Destinations deployment descriptor.
|
| $Id: destinations-service.xml 85945 2009-03-16 19:45:12Z
dimit...@jboss.org $
| --
|
| server
|
|!--
| The Default Dead Letter
jaikiran,
Okay I believe I have located the problem. I have not opened a JIRA yet because
this may well be spec, though it seems a strange spec to me (and certainly
different from JBoss 4.2.3).
Basically: the presence of an app.ear/ejbs.jar/META-INF/ejb-jar.xml file,
even an empty one,
jaikiran,
Okay I believe I have located the problem. I have not opened a JIRA yet because
this may well be spec, though it seems a strange spec to me (and certainly
different from JBoss 4.2.3).
Basically: the presence of an app.ear/ejbs.jar/META-INF/ejb-jar.xml file,
even an empty one,
jaikiran,
Yes, that worked. Terrific. Thank you so much.
If I may suggest, though, leaving off the namespace from ejb-jar is not so
weird. Lots of examples on the Web do that, and it used to work in JBoss 4.
If your ejb-jar.xml is machine generated it'll probably have a namespace, but
many
44 matches
Mail list logo
