But this is only the case if I am also writing the transactions myself right?
Meaning if I as the developer open a new transaction do a bunch of puts then
commit.
If I am just calling put over and over with no transaction code of my own in
the middle then each interaction (each put) is an indiv
Yes the slsb is writing to the same fqn every time...
As more of a philisophical question. Should a developer using jbosscache have
to worry about this (catching and retrying a failed write) or should this
behavior be inlined inside the api but only get used when the cache is
configured for opt
Manik>
Per your request I have downloaded and installed the 1.2.4 final jbosscache.jar
into my 4.0.2 jboss deployment.
I still get the same transaction exceptions with 1.2.4 final as I did with the
cvs releases.
An important thing to note is that I have 1 remote client making repeated calls
t
[EMAIL PROTECTED]
Sure thing. Where do you want me to post my findings? This topic, a new topic,
or the 1.2.4 final topic?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3902989#3902989
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting
The latest from CVS does indeed fix the JBossAS service dependancy problems. I
am now able to boot our configuration with optimistic locking enabled. So far I
have the following things to note:
1) If optimistic locking is enabled on a cacheloader enabled cache access to
that cache becomes painf
I must be looking in the wrong place...
Connected to: anoncvs.forge.jboss.com
from within eclipse
I don't see the tag:
BRANCH_JBOSSCACHE_1_2_3_FINAL
Under Branches
under versions JBossCache
or under versions jboss-cache
I must be looking in the wrong place.
View the original post :
http://w
Here is are the tree snippets that make up the fix we came up with yesterday
for our production build.
For the method:
private void insertNode(Fqn name, Map node)
| if(node != null)
| {
| //Object marshalledNode = new MarshalledValue(node);
| //
Unfortunately due to the CacheLoader startup also being busted I haven't been
able to do any testing of 1.2.4beta with jboss4.0.2. I tried moving the code
from createService back to startService as noted in this jira:
http://jira.jboss.com/jira/browse/JBCACHE-303
Then I started getting NPEs on
Found another potential problem with running the MBean inside of JBoss... When
using a JDBC CacheLoader it seems to be trying to work with the datasource
before its ready even though I have specified a dependancy on the datasource.
I checked the constructor for TreeCache and I don't see anything
Alrighty I'll grab the latest cvs source and compile it with the modified MBean
interface and give it a go.
Even as alpha I wouldn't mind checking it out. I don't plan to put it into
production I really just want to try it out and give you guys some feedback.
JBossCache saved us a ton of time w
Heya does the Optimistic Locking stuff work when using JBossCache as an MBean
within JBoss 4.0.2.
I tried dropping jboss-cache.jar into my lib directory (overwriting the old
one) and adding the attribute:
OPTIMISTIC
to my caches service.xml. Now I get the following exception:
org.jboss.deploy
Alrighty. I was just going to give it a go because the notes from the download
page:
http://jira.jboss.com/jira/secure/ReleaseNote.jspa?projectId=10051&styleName=Html&version=12310238
said it was in there in "beta" form so I thought I'd check it out and provide
feedback.
View the original post
FOUND A SOLUTION!
Each JBossAS was using DefaultPartition. One of the keys in the hashmap must be
based on this. Because as an experiment changing the partition name on one of
the servers in the all configuration caused them both to worth concurrently
without issue!
-Djboss.partition.name=MyWo
Just for completeness... here is the debug tree from eclipse for the deployment
in the default directory which is working...
PublisherSequence this= PublisherSequence (id=28)
| PublisherSequence IOS= PublisherSequence (id=27)
| String intendedServerIP= "jnp://x.x.x.155:1099"
We redeployed everything into the default directory (it was in the "All"
directory) and connections to multiple (non clustered) JBoss application
servers works now. But of course we loose the ability to have JBossAS clusters.
So the answer for us for now seems to be to support multiple connectio
Doh... I can't upload an image so here is a copy paste of the debug tree.
PublisherSequence this= PublisherSequence (id=27)
| String intendedServerIP= "jnp://x.x.155:1099"
| PublisherSequenceSecurityProxyRemote pubSeq= $Proxy3 (id=40)
| InvocationHandler h= ClientContai
Loading up my client in the Eclipse debugger I can see that its the
InvocationContext that is getting confused. So my lookups are indeed being
performed correctly but at some point that I haven't pinned down just yet the
InvocationContect is getting changed internally.
Attached is a screenshot
I might be missing something but isn't that the behavior that's desired if your
cache is REPL_SYNC. This means that a commit should only be performed after
all nodes confirm that they have the same data. If you want different behavior
try setting your cache to REPL_ASYNC
View the original pos
If you look it up through the MBean Service and use whats passed back by that
then yeah. It's basically a pass by reference. So its no different (to your
ejb) than doing a remote or local lookup of an ejb.
We have ejbs use MBeans all the time. The only time you need to be careful is
when you ge
I'm interested in knowing this as well.
We are unable to use multicast here because we have several developers on the
same subnet running many versions of jboss. But when I use the TCP
configuration jboss clustering itself works fine but jboss cache just seems to
not work (as a cluster) at all.
Last I knew only the JBoss 4.x branch is jdk 1.5 (java 5 as your calling it)
compatible.
If you try using 3.x.x with 1.5 you can expect much carnage.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3886361#3886361
Reply to the post :
http://www.jboss.org/inde
I am also using a WindowsXP/Linux hybrid cluster... No problems whatsoever.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3885747#3885747
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3885747
-
We recently upgraded from JBoss 4.0.1AS to 4.0.2AS and I believe we came across
a bug.
I have triple checked that we have all the correct jars in our remote j2ee
clients classpath but for some reason the JBoss clustering dispatcher seems to
be HA'ing JNP calls using 1099. According to the docs
Bela> 1.2.1 is working here fine for us too. You fixed that bug several weeks
ago.
>From what I've experienced 1.2.1 is rock solid.
nsakiya> Are you sure you replaced the jar?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872357#3872357
Reply to the post :
That and your bean MUST have remote interfaces...
I don't know why but without remotes I would get the same "'Deployed as
CLUSTERED but not a single clustered-invoker is bound to container" error.
Try adding remotes and remote homes to your entities (if they don't already
have them) and redeplo
te.mp> Your best bet would be to keep posting your questions here in the forums
since there are plenty of people around here more knowledgeable than me to
answer any other questions you may have.
but you can still consider me a friend if you'd like ;)
View the original post :
http://www.jboss.
The url of the wiki is here:
http://www.jboss.org/wiki/Wiki.jsp?page=JBossHA
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3865044#3865044
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3865044
---
Hey I don't know if you are still interesting in doing this... (parallelizing
JMS in your cluster instead of using it as an HA Singleton) if you are still
interested let me know...
We've succeeding in doing it here. With a few caveats we are willing to live
with.
Its not hard to do at all (I m
That worked :oD Thanks alot!
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3864837#3864837
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3864837
---
This SF.Net emai
I don't know if this will help but you could try explicitly defining the
context settings like this:
Hashtable contextSettings = new Hashtable();
| contextSettings.put("jnp.disableDiscovery", "true");
| contextSettings.put(Context.INITIAL_CONTEXT_FACTORY,
|
The jboss wiki talks about HAJMS in some detail:
http://www.jboss.org/wiki/Wiki.jsp?page=JBossHA
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3864629#3864629
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3864629
The JBoss folks have written excellent docs on clustering. It explains what
clustering in jboss means, the mechanisms and technologies they use to pull it
off. How to configure it. And they even dive into some code.
Do yourself a huge favor and get the JBoss Clustering docs
http://docs.jboss.org
Hello.
I currently have a 2 node JBoss 4.0.1 cluster running. I have two interface
adapters in each machine. the first adapter in each has an ip 155.x.x.x that
corresponds to our main subnet. The second adapter in each has its own private
non-routable ips 192.168.1.x.
I have set the bind_addr
The JBoss Clustering docs would be a great way to get started. You have to pay
for them but they are well worth it. They should tell you just about everything
you'd want to know.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861617#3861617
Reply to the post
anonymous wrote : Hopefully I can work this out, but really it seems that an
Entity Bean approach is a much better idea.
I don't know if it's too late to reply to this or not... but you could always
go the hybrid route... Which is... Use your singletons the way you are now but
anytime a method
Hey,
In porting our current architechture to JBoss 4.0 using clustering there were
quite a few Services we had that were caching state. We know that ultimately we
need to use something like JBossCache or Entities (or both) to do this
properly. But in the meantime we are just making the existing
Sorry I didn't wrap the code in proper tags so it doesn't appear in the above
post... here it is.
|
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3858607#3858607
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&
Hey all, for now in your all/conf/log4j.xml
If you set the log threshold for the console (and file) appenders to ERROR for
the package:
org.jboss.ha
These Warnings will no longer appear and you will reclaim a great deal of
performance.
the xml snippet in your log4j.xml would look like this
A sub partition seemed like the best route but according to the latest for pay
docs say on page 23 anonymous wrote : "Although JBoss does not currently
support sub-partitioning, it will soon, so let?s discuss it here."
For the heck of it I tried defining a sub partition and it almost seemed to
We are also using MySQL as our backend database for both JMS and our Entity
beans.
did you delete the
all\deploy-hasingleton\jms\hsqldb-jdbc2-service.xml
file and replace it with a suitable MySQL one?
I copied and pasted the one found in
docs/examples/jms/mysql-jdbc2-service.xml
be sure to c
This step by step how to is great. It even worked for 4.0!
You saved me hours of googling man.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3855950#3855950
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3855950
-
Well. I re-read the Clustering docs and although it didn't give me the answer
to my question directly, it did give me some things to think about which led to
a solution. I don't know that it's THEE solution but it seems to work OK.
For anyone else whos wondering here's how I am getting the parti
Actually HA jms is much easier to get working than you might think... If you
use the ALL configuration of JBoss 4.0 for example its up and going out of the
box. The ONLY change you would need to make in your clients is setting the jnp
url your clients use to connect from:
jnp://localhost:1099
reakin-tastic job at
implementing clustering.
(see why I'm called DashV? VERBOSE).
I do have one question I haven't been able to find the answer to...
Is there a way in code (like say a JMX Service MBean) to figure out what
partition the code is deployed into... Our infrastructure (wh
44 matches
Mail list logo
