[JBoss JIRA] Created: (EJBTHREE-1074) Circular @EJB3 references in session beans fail to deploy.
by Gunnar Grim (JIRA)
Circular @EJB3 references in session beans fail to deploy.
----------------------------------------------------------
Key: EJBTHREE-1074
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1074
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.1.GA
Reporter: Gunnar Grim
The following circular references makes the application undeployable:
In ArchiveBrokerBean:
@EJB
private SeriesBrokerLocal itsSeriesBroker;
In SeriesBrokerBean
@EJB
private ArchiveBrokerLocal itsArchiveBroker;
Circular references like these work fine in Glassfish but JBoss shows the following error message:
ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveTypeBroker,service=EJB3
persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU
Depends On Me:
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveOrigBroker,service=EJB3
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3
ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveOrigBroker,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3
persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU
ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3
persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU
Depends On Me:
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=ArchiveBroker,service=EJB3
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=VolumeBroker,service=EJB3
ObjectName: jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=VolumeBroker,service=EJB3
State: NOTYETINSTALLED
I Depend On:
jboss.j2ee:ear=klara5.ear,jar=klara5.jar,name=SeriesBroker,service=EJB3
persistence.units:ear=klara5.ear,jar=klara5.jar,unitName=KlaraPU
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JGRP-747) RELAY: replication between data centers
by Bela Ban (JIRA)
RELAY: replication between data centers
---------------------------------------
Key: JGRP-747
URL: http://jira.jboss.com/jira/browse/JGRP-747
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.x
[from JGroups/doc/design/DataCenterReplication.txt]
Replication between data centers
================================
Author: Bela Ban
Version: $Id: DataCenterReplication.txt,v 1.6 2008/04/25 15:54:30 belaban Exp $
We have data centers in New York (NYC) and San Francisco (SFO). The idea is to replicate traffic from NYC to SFO
asynchronously. In case of a site failure of NYC, all clients can be switched over to SFO and continue working with
(almost) up-to-date data. The failing over of clients to SFO is outside the scope of this proposal, and could
be done for example by changing DNS entries, load balancers etc.
There is no replication going on from SFO to NYC by default, only when SFO becomes the primary site.
The assumption is that there is no message between data centers which requires a response. This would require
NAT functionlity, which we may provide in a future version.
For the example, we assume that each site uses a UDP based stack, and replication between the sites use a
TCP based stack, see figure DataCenterReplication.png.
There is a local cluster, based on UDP, at each site and one global cluster, based on TCP, which connects the
two sites. Each coordinator of the local cluster is also a member of the global cluster, e.g. member E in NYC
(assuming it is the coordinator) is also member X of the TCP cluster. This is called a *relay* member. A relay
member is always member of the local and global cluster.
A relay member has a UDP stack which additionally contains a protocol RELAY at the top (shown in the bottom part
of the figure). RELAY has a JChannel which connects to the TCP group, but *only* when it is (or becomes) coordinator
of the local cluster. The configuration of the TCP channel is done via a property in RELAY.
Any *multicast* message (we don't relay unicast messages) that is received by RELAY traveling
up the stack is sent via the TCP channel to the other site. When received there, the corresponding RELAY
protocol changes the destination of the message to null (those are multicast messages after all) and leaves
the src (which might point to X if sent from NYC), then it sends the message down the stack, where it will get
multicast to all members of the local cluster (including the sender). When a response is received which
points to any non-local address (e.g. X), RELAY simply drops it.
When forwarding a message to the local cluster, RELAY adds a header. When it receives the multicast message it
forwarded itself, and a header is present, it does *not* relay it back to the other site but simply drops it.
Otherwise, we would have a cycle.
When a coordinator crashes or leaves, the next-in-line becomes coordinator and activates the RELAY protocol,
connecting to the TCP channel and starting to relay messages.
However, if we receive messages from the local cluster while the coordinator has crashed and the new one hasn't taken
over yet, we'd lose messages. Therefore, we need additional functionality in RELAY which buffers the last N messages
(or M bytes, or for T seconds) and numbers all messages sent. This is done by the second-in-line.
When there is a coordinator failover, the new coordinator communicates briefly with the other site to determine
which was the highest message relayed by it. It then forwards buffered messages with lower numbers and removes the
remaining messages in the buffer. During this replay, message relaying is suspended.
Therefore, a relay has to handle 3 types of messages from the global (TCP) cluster:
(1) Regular multicast messages
(2) A message asking for the highest sequence number received from another relay, and the response to this
(3) A message stating that the other side will go down gracefully (no need to replay buffered messages)
Example walkthrough
-------------------
- C (in the NYC cluster, with coordinator E) multicasts a message
- A, B, C, D and E receive the multicast
- D (second-in-line) buffer the message (bounded buffer)
- E is the relay. The byte buffer is extracted and a new message M is created. M's source is C, the dest is null
(= send to all). Note that the original headers are *not* sent with M. If this is needed, we need to revisit.
- X receives M, drops it (because it is the sender, determined by the header).
- Y receives M, adds a RELAY header and sends it down the stack
- T, U, V, W and S receive M and deliver it
- Y does not relay M because M has a header
- Should some member reply (to X), then RELAY at Y will drop the message
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (EJBTHREE-1045) Improve error message when binding fails
by Carlo de Wolf (JIRA)
Improve error message when binding fails
----------------------------------------
Key: EJBTHREE-1045
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1045
Project: EJB 3.0
Issue Type: Feature Request
Affects Versions: AS 4.2.1.GA
Reporter: Carlo de Wolf
Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD
2007-09-03 14:58:50,737 WARN [org.jboss.system.ServiceController] Problem starting service jboss.j2
ee:ear=jbilling.ear,jar=jbilling.jar,name=com/xxx/yyy/server/item/ItemSession,service=EJB3
java.lang.ClassCastException: $Proxy76 cannot be cast to javax.naming.Context
at org.jboss.util.naming.Util.createSubcontext(Util.java:69)
at org.jboss.util.naming.Util.rebind(Util.java:125)
at org.jboss.util.naming.Util.rebind(Util.java:113)
at org.jboss.ejb3.stateless.StatelessRemoteProxyFactory.start(StatelessRemoteProxyFactory.java:115)
In EJB 3 a stateful session bean can be created directly via a loopup on it's business interface. By default this one is bound to <ejb-name>/remote (or /local). The home interface is bound to <ejb-name>/home (or /localHome). If you override the JNDI name for the bean by <ejb-name> then this exception occurs. The log file should show "Binding proxy for <ejb-name> in JNDI at <jndi-name>" just before this happens.
It should say an error message in the likes of:
"Can't bind ItemSession/remoteHome, because ItemSession is already bound"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBAS-4810) mail-ra.rar make SSL configurable
by Kurt Stam (JIRA)
mail-ra.rar make SSL configurable
---------------------------------
Key: JBAS-4810
URL: http://jira.jboss.com/jira/browse/JBAS-4810
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.1.GA
Reporter: Kurt Stam
Assigned To: Weston Price
Attachments: mail-ra-patch.txt
We are using it in JBossESB now, but in my (test) case I did not want SSL with my IMAP
connection, so I'm suggesting to make this setting configurable in the
connector/src/main/org/jboss/resource/adapter/mail/inflow/MailFolder.java
- sessionProps.setProperty("mail.imap.starttls.enable", "true");
+ sessionProps.setProperty("mail.imap.starttls.enable", starttls + "");
I have attached the patch.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months