The new JBossJMS implementation will replace JBossMQ and there are plans to integrate
a JGroups-based transport as well. More details can be found at
http://www.jboss.org/wiki/Wiki.jsp?page=JBossJMS,
http://www.jboss.org/wiki/Wiki.jsp?page=JBossJMSDesign
http://www.jboss.org/wiki/Wiki.jsp?page=
A start point: http://www.jboss.org/wiki/Wiki.jsp?page=SecureTheJmxConsole
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3838209#3838209
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3838209
--
It is similar for web applications. Use resource-ref.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3838032#3838032
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3838032
---
Yes, obviously step 3 should be:
| Context initCtx = new InitialContext();
| Context compEnv = (Context)initCtx.lookup("java:comp/env");
| DataSource ds = compEnv.lookup("jdbc/MyAccessToPostgresDS");
|
It wouldn't make sense to look up compEnv and not use it. I type faster than I think
:
Are you sure your ejb-jar.xml deploys fine? I am asking this because my jboss instance
says something like "The Bean Provider must provide a remote interface and a remote
home interface or a local interface and a local home interface for the bean." when I
am trying to deploy a ejb-xml.jar that
Your component should look up the resouce factory in its Enterprise Naming Context
("java:comp/env") using a resource reference. For that:
1. Declare a resouce reference in ejb-jar.xml:
|
| MySession
| ...
|
| jdbc/PostgresDS
| javax.sql.DataSource
|
If I remeber well, this is because SGI's VM doesn't support -server option. Try
commenting out that in run.sh.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3834129#3834129
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p
A JRMPInvoker (Service MBean, RemoteServer, etc) is plugged into the JMX spine and
sits there listening for remote invocations and putting them on the invocation bus.
It's server-side.
The client-side object that starts the invocation sequence is a dynamic proxy, created
by a JRMPInvokerProxy
If performances degrades with the number of clients, and you're using multicast, my
first intuition would be that NAKACK does a lot of retransmission.
Bela, doesn't NAKACK have debugging statements that get triggered by retransmission?
You can enable debugging for NAKACK and see if this is the
The protorype doesn't do any message acknowledgement at application level.
The stack is configured with pbcast.NAKACK.
Interesting.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827450#3827450";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=repl
Yes, I'll do that (experimenting). I'll get back with conclusions.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827439#3827439";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827439>Reply
to the post
It is counter-intuitive, indeed.
I'll try to do some more extensive tesing myself with both text and byte messages
today or maybe tomorrow and I'll get back to you.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827424#3827424";>View
the original post
http://www.jboss.org/index.html
Are you experimenting just with hardware multicast or you bridge messages over to a
TCP-based group?
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827313#3827313";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827313>Reply
to the post
sljms.xml is identical to default.xml from JGroup's conf directory. It is the standard
multicast stack JGroups comes with.
fc-fast.xml is a variation of the above, in that it enables bundling (UDP protocol
waits until it has a buffer full of data or a timer expires, and then sends data on
the
It is trivial. Support for all JMS Message types will be added in the next release.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827155#3827155";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827155>Reply
to the post
--
Release 0.1.2 is available at:
http://www.feodorov.com/tmp/sljms-0.1.2.tar.gz
The master documentation file is doc/index.html
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826617#3826617";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=38
A version that contains everything you need to experiment with your "relaying"
solution is ready to be released. I don't want to call it 0.2. Not that the name
matters, anyway, but 0.2 was supposed to include persistent delivery, and I am still
working on that.
I will post the URL on the forum
Your solution is in principle correct, and, oddly enough, almost possible to implement
with the current alpha release.
Basically, you'll have to write a "bridge client", that creates two connections to two
different serverless JMS providers. The first one runs over the multicast domain and
the
The current implementation uses only one "control channel" per Connection. All
channels must be configured the same way (same stack configuration file) in order to
join the group. Control traffic and payload traffic share the channel.
A very sensible idea is to use a different channel or more, w
19 matches
Mail list logo
