Sounds like you are missing stuff on the caller's classpath. What JBoss AS
release?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227512#4227512
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227512
__
I don't see any reason why this shouldn't work differently with
org.jboss.invocation.jrmp.server.JRMPInvokerHA than it does with the
non-clustered org.jboss.invocation.jrmp.server.JRMPInvoker.
As a diagnostic exercise, if you tweak your config to base it off the
non-clustered "Standard Stateles
In the past I've clustered JBoss AS between my Windows XP box and my Fedora 9
x86_64 box. That includes JBoss Cache. I didn't do any extensive testing, but
the nodes clustered and HTTP session replication worked.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p
No, you can't get access to the JChannel, and if you did that send() call
wouldn't work. HAServiceMBeanSupport provides a callMethodOnPartition method
that lets you invoke an RPC on the group; you could pass the target node as a
param.
If you can use AS 5.1 (now in CR1 release) HAPartition als
The connections to 1199 and 1198 are for a JNDI lookup. The 5446 connection is
most likely made by an EJB proxy that was returned by the JNDI lookup.
Have a look at the config of the
"jboss.remoting:service=Connector,transport=socket" mbean in
conf/jboss-service.xml. By default the "serverBin
For draft docs on AS 5 clustering, see the file attached at the *bottom* of
https://www.jboss.org/community/docs/DOC-12928 . It includes a Quick Start
section.
But, you're already doing what it says.
Seems there is some problem parsing what you are passing on the command line;
this isn't a clu
>From the ports you've described, I assume you are using the
>ServiceBindingManager. For this remoting Connector mbean, it's doing an XSL
>transform; perhaps there is a problem there?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4229066#4229066
Reply to the
Your config says:
4446
but the service is listening on 5446. That tells me you are using the
ServiceBindingManager. For more on that see
http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/beta422/html/Additional_Services-Services_Binding_Managemen
If it is due to the ServiceBindingManager, you'd have the same problem with
ports-default.
You can confirm it's due to the SBM by commenting out the following in
conf/jboss-service.xml. If the problem goes away, it's the SBM.
|
| ports-01
| ${jboss.home.url}/docs/examples/bin
Do you still see this problem with community AS 5.1.0.CR1?
The injection of the HAPartition isn't working because you're using
-jboss-beans.xml syntax in a -service.xml. It should be:
The element name is "attribute" not "property".
View the original post :
http://www.jboss.org/index.html?mo
"amardeep21" wrote : I have commented ports-01 but it makes no difference.
Just to be clear: you commented the entire mbean, right?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4229454#4229454
Reply to the post :
http://www.jboss.org/index.html?module=bb&op
No need to apologize. It might still be there, but it's in an area in active
development that's outside of my regular involvement. So first thing to do
before doing deep analysis is to check if it's already fixed. :)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopi
Do you package a copy of the javax.management.ObjectName class in Test.ear?
Please outline the contents of Test.ear.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4229490#4229490
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=r
Community member amardeep21 is reporting issues with the AS 4.2.2
"jboss.remoting:service=Connector,transport=socket" Connector where it looks to
not be respecting the jboss.bind.address. See
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154855 . Can anyone
from the Remoting communi
Sorry for the wild goose chase with the SBM. I suspect there is something
obvious we're missing, as I'd think if that connector wasn't respecting the -b
value I'd have heard about it long before. I've pinged the Remoting folks
(http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155089) to
Oh, I completely misunderstood the problem! I thought the calls going to
staticip:5446 were hitting the same AS instance as the calls to vpnip:109x, but
were coming in on the wrong interface.
What is being looked up with the JNDI calls? I expect it's an EJB session bean.
Stateless or Stateful?
If you don't get a reply from the community here, suggest you post on the JBoss
Messaging forum.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4229526#4229526
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4229526
_
Your category names are wrong. Rule for figuring out the classname of a JGroups
protocol from the name of it's config element in a protocol stack configuration
is:
org.jgroups.protocols. + element-name
(Note there's no "jboss" in the package -- JGroups long predates it's
association with JBoss
There may be stuff you can do, but I'm not sure what your goals are. Simplest
is separate clusters for the staticip machines vs the vpnip machines. Those two
clusters can be linked in some ways, but that gets complicated and before
getting into it I'd need to know in what ways you'd want them li
With AS 5.0.1 you need to manually copy your application to the deploy dir on
each of your nodes.
In AS 5.1.0 the farming capability has been restored; see
http://www.jboss.org/community/wiki/FarmDeploymentsinJBossAS5x.
View the original post :
http://www.jboss.org/index.html?module=bb&op=view
Use -Djboss.bind.address=0.0.0.0 -Djgroups.bind_addr=0.0.0.0
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234814#4234814
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4234814
__
Yep. The principal is not stored in the session, so replicating the session
doesn't propagate it around the cluster. Using ClusteredSingleSignOn works
around the problem.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4234815#4234815
Reply to the post :
http
See the AS 5 part of the discussion under the "Providing alternate ports for
each instance of JBoss AS" section of
http://www.jboss.org/community/wiki/ConfiguringMultipleJBossInstancesOnOneMachine.
That;s most likely what you need.
For a whole lot of detail, see also
http://www.jboss.org/commu
Sorry, you posted this right before I left on vacation.
HAServiceMBeanSupport exposes a "registerThreadContextClassLoader" boolean
property. Does setting that to true, either in your service's XML config or in
code before the call to super.startService(), let you leave the
loader-repository in
Sorry for the delayed response; I've been away.
Yep, you've found a problem:
https://jira.jboss.org/jira/browse/EJBTHREE-1842
Thanks for the very thorough report.
Your workaround of removing ClusteredIsLocalInterceptor should work OK,
although I agree it's not ideal.
View the original post :
Just update the file and save it. The status worker rescans the file every 60
secs and updates the server.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235476#4235476
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=423
You're not wrong; the docs are still out of date. Use the attachment at the
bottom of https://www.jboss.org/community/wiki/JBossAS5ClusteringGuide[/url]
for the latest draft; see also pages linked off of
[url]http://www.jboss.org/community/wiki/MajorClusteringChangesinJBossAS5.
Whatever is not
What is the traffic between the "front end" and the "middleware"? EJB
invocations?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236458#4236458
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236458
___
Yes, add new port configurations manually.
Or, add virtual ips to some of your NICs and bind some of your instances to
different IPs.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236774#4236774
Reply to the post :
http://www.jboss.org/index.html?module=bb
My apologies. I've had that "just update workers.properties" idea in my head
for a long time, don't know where it came from, but it's just wrong.
A couple suggestions for you:
1) If you are using JBoss 5, try mod_cluster
http://www.jboss.org/mod_cluster/
One of the primary motivations for its
For securing the transports used for EJB invocations, see
http://www.jboss.org/community/docs/DOC-11987 for EJB2
and
http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/transport.html
for EJB3.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopi
I've never heard of any problems with using a build on multiple platforms and
don't expect there to be any. The AS itself doesn't produce separate builds.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237706#4237706
Reply to the post :
http://www.jboss.org
The jnp.localAddress property in your jndi.properties will control what
interface the client side naming context binds its socket on. See discussion of
that property on
http://www.jboss.org/community/wiki/NamingContextFactory
If that doesn't resolve your issue, please include all your naming en
What AS release?
The cluster-service.xml isn't the only relevant config file. There are also
JGroups channels opened for HttpSession replication, EJB3 SFSB replication and
EJB3 entity caching (if your AS version supports EJB3). Where in deploy the
configs for those are depends on what AS rele
TCP definitely doesn't scale as well as UDP multicast. But whether that is a
real issue depends on what kind of traffic you have between the nodes. The
services that generate a lot of traffic over the JGroups channels are
1) HttpSession replication
2) EJB StatefulSessionBean replication
3) Hibe
The default clustering behavior in AS 5 can be controlled via the
server/XXX/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml
file.
|
|
|
| standard-session-cache
|
| field-granularity-session-cache
|
|
What AS version are you using?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238008#4238008
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238008
___
jboss-user mailing list
Leonets: is your webapp continuing to use the same connection to the JMS
server? Or are you closing connections and creating new ones?
Per JBoss Messaging docs[1] connection creation is load balanced, but once a
connection is created it will stick to one server (unless failover happens).
[1]
h
By the "multi-home" limitation do you mean configuring the bind address in the
JGroups UDP protocol? That's pretty straightforward.
You can control the interface JGroups uses by setting system property
-Djgroups.bind_addr=192. as a command line argument.
If don't specifically set jgroups.b
JBoss does the same basic thing with the java.rmi.server.hostname system
property
1) Do nothing if already set (e.g. via -Djava.rmi.server.hostname)
2) else if the -b value isn't 0.0.0.0, set java.rmi.server.hostname to the -b
value
3) else set java.rmi.server.hostname to
InetAddress.getLoc
Container-based auth is required. See "Limitations" section of
http://www.jboss.org/community/wiki/JBossWebSingleSignOn.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239520#4239520
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mo
Thanks, nbelaevski for pointing out how code outside the container can't
synchronize on the session, only the facade. And thanks Scott for running with
this.
The concern I have is StandardSession.facade is not thread safe, and what's
returned from getSession() needs to be if we are going to use
Scott, this gets trickier in AS 5. In AS 5 the serialization of the attributes
is deferred until JBoss Cache needs to serialize for replication. Which happens
in ClusteredSessionValve.handleRequest:
[code
]finally
{
if (startedBatch)
{
tm.e
Thanks. But I need more context to understand what you are describing. So, a
couple questions:
1) Do you see this NPE when using 5.0.0.GA, 5.0.1.GA or 5.1.0.GA?
2) If yes, can you provide the full stack trace?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=424
Do you mean you are using EAP 4.3? Or JBoss 4.2.3? If it's EAP 4.3 and you have
a support contract, I recommend you open a support ticket on the Customer
Service Portal, where there's an SLA.
In your other environment where you aren't seeing the asterisks, the webapp
must not have the
element
anonymous wrote : Anyway Connection conn is an istance variable in the doGet
servlet method
You mean a local variable?
If so, yeah, you're not caching it, so new connection creation should be load
balanced. If closing the connection doesn't resolve your problem I suggest you
post on the JBoss
Try a GA release. :)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240131#4240131
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4240131
___
jboss-user mailing list
jboss-user
"smar...@redhat.com" wrote : Brian,
|
| We will have to try to get access to the StandardSessionFacade from there
as well (perhaps through the ClusteredSession).
|
|
Yes. The tricky bit is if there are multiple sessions being replicated (as part
of a cross-context request.) See bel
Good. :-) I very deliberately eliminated the double buffering because of the
memory cost.
FYI, before this thread got going I'd been thinking (vaguely) in terms of using
read/write locks in AS 6 to better handle coordination. E.g., in
ClusteredSessionValve acquire a RL before passing the reques
If we use a R/W lock, there shouldn't be any application activity during the
periods where we are serializing etc. The WL we acquire prevents it.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4240412#4240412
Reply to the post :
http://www.jboss.org/index.htm
Good question. This topic deserves a wiki page of its own.
Simplest way to solve your problem:
1) Include the following in your command line args that you pass to JBoss:
-Djboss.default.jgroups.stack=tcp
That will change most of the services that use a JGroups channel to use one
based on the "
The key is acquiring a RL in ClusteredSessionValve:
|// let the servlet invocation go through
|Lock lock = manager.getReadLock(requestedSessionId);
|lock.lock();
|try
|{
| if (isEvent)
| {
| getNext().event(request, respons
"jjfevs" wrote :
| I read the TwoClustersInTheSameNetwork document in JBoss online docs, and
yesterday we have applied a workaround explained there in another environment
(that is a exact replica of this one). This was about setting
emptySessionPath=false in the connector in jboss-web.deploye
To answer your #1 and #3, the key thing is to hold the WL for the minimum
required time. You only have to hold it long enough to:
a) Accurately determine if anything needs to be replicated
b) Copy that into the DTO that's passed to the replication layer.
c) Serialize attributes.
Ideally a) and b
Thanks.
The companion issue for JBAS-5810 that tracks the issue for EAP is
https://jira.jboss.org/jira/browse/JBPAPP-1021 . That JIRA shows a fix for EAP
4.3.0.GA_CP03. If you use CP03 or later, do you still see the problem?
View the original post :
http://www.jboss.org/index.html?module=bb&op
Thanks, giddion for the correction and the details. Yep, in my comment format
for the initial_hosts list was incorrect.
Note that if you use -b 0.0.0.0, JGroups will not bind to all interfaces.
Rather it ends up using the value returned by
InetAddress.getLocalHost().getHostName(). You can contr
The "DEPLOYMENTS MISSING DEPENDENCIES:" error message is rather cryptic; I'm
looking into it to make sure it means what I think it means. But my
interpretation is not that the microcontainer expects the bean to be in
"Described" but rather that it doesn't recognize the name at all.
Looking at t
"bstansbe...@jboss.com" wrote : Hmm, a possibility here is the
BarrierController is directly registering the Barrier in JMX, and the
microcontainer is bypassed. So the microcontainer is unaware of the barrier.
OK, I checked that theory out and the microcontainer isn't bypassed;
I tried deploying a simple pojo with a dependency on the barrier:
|
|
|
|
| jboss.ha:service=HASingletonDeployer,type=Barrier
|
|
|
|
That gave me the result I expected on the 2nd node
anonymous wrote :
| DEPLOYMENTS MISSING DEPENDENCIES:
|
Yes, please do. In the JBAS project. Actually, I see two issues in this thread:
1) Figuring out why the @Depends on your EJB results in a different error
message than the expected one that I got when I deployed my example POJO.
2) Coming up with a mechanism to avoid the ERROR message altogether
I (or you or nbelaevski if either is up for it) need to review the session
replication code to see how much of an issue this is. I haven't had cycles to
do that, which is why my comments here are vague.
If the issue is only protecting the attributes, then synching on the facade in
the places w
How are you deploying the file? Placing it in farm on one node? Copying it to
farm on both? Copying it to both and then starting the 2 nodes?
I'd think the first, but I want to be sure.
I'll assume it's the first and the node where it successfully deployed was the
one where you copied the file
The PDF version of the docs linked from
https://www.jboss.org/community/wiki/JBossAS5ClusteringGuide[/url] is a
somewhat updated draft, but still has a fair amount of old stuff in it,
particularly around configuration of the HAPartition as well as some of the web
tier stuff. A good resource is
After your step 3, check your browser for what cookies you've got. You should
see a JSESSIONIDSSO cookie. Do you?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242019#4242019
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=repl
Patrick,
Looking at the log files you sent I'm seeing JGroups doing a lot of
retransmission of messages. Basically for each ~60K of content JGroups sends a
message; if the receiver detects some messages are missing it asks for
retransmission of the missing message and won't deliver messages to
1) Use sticky sessions. If you don't you are asking for trouble.
2) If you disregard #1, there shouldn't be any harm in leaving UseJK=false. The
purpose of the JvmRouteValve is to allow the session to stay stuck after
failover.
3) I've never tried to use mod_jk without configuring a jvmRoute. Q
Each AS instance will have its own MBeanServer.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242476#4242476
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242476
___
jboss-u
Mod_jk with sticky sessions routes requests based on the jvmRoute appended to
the session id in the session cookie. The failure of one of your Apache nodes
does not mean sticky sessions won't work, since such a failure doesn't affect
the session cookies.
For more on the sticky session recommend
Right; no Remoting issue. Just me needing to correctly understand his problem
and explain how clustering works.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242916#4242916
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&
Right. Running more than one Apache node to avoid a single point of failure at
that level is best practice.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242982#4242982
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=42
Please see this thread:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157684
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242984#4242984
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242984
__
Thanks for the info; got your logs. The log shows a burst of messages being
received, each of which is a piece of the file, and then a 60 second pause
before the next burst.
Suspiciously, 60 secs is the default timeout for waiting for group RPC
responses, hinting that something around that' i w
For info on custom usage of JBoss CacheSee Chapter 11, particularly section
11.2, in the Clustering Guide draft (available in PDF via
[/url]https://www.jboss.org/community/wiki/JBossAS5ClusteringGuide). For
general JBC usage information, see the JBoss Cache 3 documentation.
View the original po
See http://www.jboss.org/community/docs/DOC-12658 for a discussion of the need
for sticky sessions.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244344#4244344
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244344
__
The "Possible concurrency problem" problem usually means that sticky sessions
aren't working. Request 3 updates session state on server A and then request 4
goes to server B and accesses the session before the replicated state from
request 3 arrives.
View the original post :
http://www.jboss.o
What's being logged there is the value that will be returned to naming clients
trying to discover HA-JNDI via multicast autodiscovery. Here's how the value is
derived:
| String address = getBindAddress();
| /* An INADDR_ANY (0.0.0.0 || null) address is useless as the value
What AS version?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243944#4243944
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4243944
___
jboss-user mailing list
jboss-user@lis
Very strange. What I'm seeing is it works as expected when I set the properties
on the command line, but when I edit run.conf.bat to include them in JAVA_OPTS,
I get the behavior you reported.
Ah! I get it. The code that fixes the jgroups.bind_addr property if it's
0.0.0.0 is part of the proce
Hmm, I just noticed that last bit was running in an old pre-5.1.0.CR1 build.
I'll try again.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245407#4245407
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245407
_
No ideas. It works for me:
| C:\dev\jboss\Branch_5_x\build\output\jboss-5.1.0.CR1\bin>run -c all
-Djboss.bind
| .address=0.0.0.0 -Djgroups.bind_addr=0.0.0.0
|
===
|
| JBoss Bootstrap Environment
|
|
You're not using a clustered EJB. If you want a cluster-aware EJB proxy you
need to add @Clustered to your EJB3 bean class or add
true
to the bean's section in jboss.xml.
HA-JNDI makes the naming operations HA, it doesn't automagically make the stuff
bound in JNDI cluster-aware.
View the orig
I'm not aware of any JBoss code that uses broadcast. Certainly not in the
clustering libraries, which only use multicast or unicast.
Suggest you use a tool like wireshark to track down what these packets are.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248
Right; there's no mechanism to migrate. You can open a JIRA if you want to
request that as a feature. Even better, implement it. :-)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250032#4250032
Reply to the post :
http://www.jboss.org/index.html?module=bb&o
Haha! I love the honesty!
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250208#4250208
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250208
___
jboss-user mailing list
jbos
If JBoss detects that the target EJB is running in the same VM, it will routes
calls to the in-VM bean rather than sending them remotely. Effect is such
calls aren't load balanced across the cluster.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250209#4250
This comment needs to be fixed:
Should be something more like this:
https://jira.jboss.org/jira/browse/JBAS-7206
You then "fix" the port value (i.e. prevent the offset being applied) by
setting the "fixedPort" property, same as you would for one of the elements in
the StandardBindings set.
Does your application initiate transactions on the client side?
If so, removing the ClusteredIsLocalInterceptor can lead to problems described
at https://jira.jboss.org/jira/browse/EJBTHREE-1005. TBH I believe replacing a
ClusteredIsLocalInterceptor with something custom would face the same prob
Thanks for pointing that out. I just updated the wiki page to add more on this
topic. But there's some problem going on with publishing the change, so it may
be a while before the new content appears.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251267#4251
This sounds like https://jira.jboss.org/jira/browse/JBAS-7123 . If you post the
full stack trace of your "java.lang.RuntimeException: DistributedCacheManager
is null.
at org.jboss.web.tomcat.service.session.ClusteredSession.establishDistri
butedCacheManager(ClusteredSession.java:1773) " I can con
I doubt this has anything to do with clustering per se; rather it's that
clustering is a feature in the "all" config, along with lots of other stuff
that's not in default, e.g. deploy/iiop-service.xml.
Does removing deploy/iiop-service.xml solve your problem? Alternatively, you
could try making
I suggest you ask on the JBoss Messaging user forum. The docs referenced above
indicate that a connection will stick to one server unless a failover event
occurs. If there's some mechanism to change that (from the docs, it sounds
unlikely) the folks on the messaging forum are the ones to tell yo
When you say "without bringing down JBoss" are you saying you want to run 2
versions of the app concurrently in the same JBoss instance? Or are you talking
about a rolling upgrade of a cluster?
If the latter, the solution involves the mod_jk and mod_cluster notion of
"domains", which are essent
So it sounds like you want your producers and consumers to only be deployed on
the HASingleton master. So, seems like you should:
1) Follow the instructions on
http://www.jboss.org/community/wiki/IntegrationWithTibcoEMS
And it sounds like you've done that and gotten it working.
As you've disc
Thanks for the stack trace; yeah that's the JBAS-7123 condition.
It's already fixed in SVN and will be fixed in the 5.2 which should be out late
this year. It will also be fixed in JBoss Enterprise Application Platform 5.
As to a workaround for AS 5.1.0, the only one I can see is to add this to
Should be possible, yeah.
I haven't tried this myself, so beware, test carefully, be prepared for
possible bumps in the road etc.
But you should be able to:
1) Remove the server/all/deploy-hasingleton/jms folder
2) Replace the contents of server/all/deploy/jms with those from
server/default/de
First off, if you are using EAP you are quite likely a support customer. If so
you should open a ticket on the Customer Support Portal, where you'll get much
better support than I can provide in the half hour or so I day I spend on this
forum.
A basic debugging step is to take a heap histogram
Perhaps this?
http://www.jboss.org/community/docs/DOC-9241
I haven't used it myself so can't answer questions, but it's good stuff.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212276#4212276
Reply to the post :
http://www.jboss.org/index.html?module=bb&o
I think you'll have more luck on the JBoss Messaging forum.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4212469#4212469
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4212469
___
Can you post the rest of the logging for this transaction? I want to see why
GlobalTransaction::2 is holding a lock on /com/foo/Bar/ENTITY. If all you've
done during the tx is a single bulk UPDATE it shouldn't be holding any lock.
View the original post :
http://www.jboss.org/index.html?module=
Is there anything from Hibernate before the first bit in the "TRANSACTION
(EXECUTES A SINGLE BULK UPDATE QUERY!)":
| 2009-02-26 12:54:50,032 TRACE
[org.jboss.cache.interceptors.InvocationContextInterceptor] main - http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213783#4213783
Reply
1 - 100 of 329 matches
Mail list logo
