May 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1818) Embedded should not impose version range constraints

by Carlo de Wolf (JIRA)

Embedded should not impose version range constraints ---------------------------------------------------- Key: EJBTHREE-1818 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1818 Project: EJB 3.0 Issue Type: Bug Components: embedded Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: embedded-1.0.0-alpha-2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1816) Undeployment of EJBs fails because Ejb3Registrar is already undeployed

by Carlo de Wolf (JIRA)

Undeployment of EJBs fails because Ejb3Registrar is already undeployed ---------------------------------------------------------------------- Key: EJBTHREE-1816 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1816 Project: EJB 3.0 Issue Type: Bug Components: embedded Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: embedded-1.0.0-alpha-2 08:18:14,362 INFO [SessionSpecContainer] Stopping jboss.j2ee:jar=tests-classes,name=GreeterBean,service=EJB3 08:18:14,362 WARN [StartStopLifecycleAction] Error during stop for jboss.j2ee:jar=tests-classes,name=GreeterBean,service=EJB3 org.jboss.ejb3.common.registrar.spi.NotBoundException: Could not retrieve Ejb3Registrar as a registrar implementation has not yet been bound. at org.jboss.ejb3.common.registrar.spi.Ejb3RegistrarLocator.locateRegistrar(Ejb3RegistrarLocator.java:85) at org.jboss.ejb3.session.SessionContainer.getJndiRegistrar(SessionContainer.java:319) at org.jboss.ejb3.session.SessionContainer.lockedStop(SessionContainer.java:239) at org.jboss.ejb3.session.SessionSpecContainer.lockedStop(SessionSpecContainer.java:600) at org.jboss.ejb3.stateless.StatelessContainer.lockedStop(StatelessContainer.java:276) at org.jboss.ejb3.EJBContainer.stop(EJBContainer.java:923) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-659) Merge and UNICAST sequencing problem

by Vladimir Blagojevic (JIRA)

Merge and UNICAST sequencing problem ------------------------------------ Key: JGRP-659 URL: http://jira.jboss.com/jira/browse/JGRP-659 Project: JGroups Issue Type: Bug Affects Versions: 2.6, 2.5, 2.4 Reporter: Vladimir Blagojevic Assigned To: Bela Ban The problem is related to trashing of connection table in UNICAST during merge. Consider following scenario: There are 4 nodes in a cluster A,B,C, and D. After network split we have two islands A,B and C,D. When the network healing starts eventually MergeView gets installed in both islands. MergeView installation causes trashing of UNICAST connection table [1]. However if we have a scenario where MergeView gets installed in A,B island at time T and it gets installed in island C,D at time T+N msec and a node from island A,B sends a unicast message in this N msec time window then we'll run into problems with unicast sequencing at C and D. Why? Because next message coming from island A,B into C,D will be will with sequence number > 1 and sequencing in UNICAST of C,D after connection trashing (from merge) expects starting sequence of 1. This causes UNICAST in C and/or D to wait forever for missing messages. Final outcome is thus that no more unicast message coming from A and/or B will ever be delivered at C and/or D! [1]http://jira.jboss.com/jira/browse/JGRP-348 -- 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

17 years, 2 months

3
16
0 / 0

[JBoss JIRA] Created: (JBAS-5146) com.sun.faces.serializeServerState , java.lang.ClassNotFoundException: boolean

by Dave Chen (JIRA)

com.sun.faces.serializeServerState , java.lang.ClassNotFoundException: boolean ------------------------------------------------------------------------------- Key: JBAS-5146 URL: http://jira.jboss.com/jira/browse/JBAS-5146 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: JBossAS-4.2.2.GA Environment: JBoss 4.2.2.GA, using JSF RI with Tomahawk. Reporter: Dave Chen Assigned To: Stan Silvert Priority: Critical I am using <t:saveState>, and set com.sun.faces.serializeServerState to true in web.xml. <context-param> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> <param-value>server</param-value> </context-param> <context-param> <param-name>com.sun.faces.serializeServerState</param-name> <param-value>true</param-value> </context-param> I got the following exception. java.lang.ClassNotFoundException: boolean at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1358) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at com.sun.faces.renderkit.ApplicationObjectInputStream.resolveClass(ApplicationObjectInputStream.java:74) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1433) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1288) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.ArrayList.readObject(ArrayList.java:591) -- 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

17 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2384) Avoid creating dashborad objects if dashboard isn't used

by Thomas Heute (JIRA)

Avoid creating dashborad objects if dashboard isn't used -------------------------------------------------------- Key: JBPORTAL-2384 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2384 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Reporter: Thomas Heute Fix For: 2.7.3 Final Dashboard portal objects are created even if a user never uses his dashboard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JGRP-130) Problems with reincarnation

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-130?page=com.atlassian.jira.plugi... ] Bela Ban resolved JGRP-130. --------------------------- Resolution: Done This works now with 2.8.Alpha3. The attached config and sample run works correctly now > Problems with reincarnation > --------------------------- > > Key: JGRP-130 > URL: https://jira.jboss.org/jira/browse/JGRP-130 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.8 > > Attachments: tcp.xml, tcp_vicnov.xml > > > Problems with reincarnation > =========================== > Author: Bela Ban > Version: $Id$ > The identity of a JGroups member is always the IP address and a port. The port is usually chosen by the OS, unless > bind_port is set (not set by default). > Let's say a member's address is hostA:5000. When that member dies and is restarted, the OS will likely assign a > higher port, say 5002. This depends on how many other processes requested a port in between the start and restart > of the member. > JGroups relies on the fact that the assignment of ports by the OS is always (not necessarily monotonically) > *increasing* across a single machine. If this is not the case, then the following problems can occur: > 1. Restart: > When a member P crashes and then is restarted, if FD is used and P is restarted *before* it is excluded, > then we have a new member *under the same old address* ! Since it lost all of its state (e.g. retransmission table), > retransmission requests sent to the new P will fail. > 2. Shunning: > Regarding shunning: a member keeps its last N (default is 100) ports used, and makes sure it doesn't reuse one of > those already-used ports when it is shunned. However, this is process-wide and *not* machine-wide, e.g. when we have > processes P1 on A:5000 and P2 on A:5002 (on machine A), and both of them are shunned at the same time, > when they rejoin, P1 does not use port 5000, but might use port 5002, and P2 doesn't use 5002, but might use 5000, so > they could assume each other's identity ! > Both problems cannot be solved by remembering the last 100 ports: in case #1, this list is lost because we start a > new process and in case #2, the list is process-wide, but not machine-wide. > Again, these problems occur *only* when the OS reuses previously assigned ports. > SOLUTION: > A: Use temporary storage (per host) to store the last N addresses assigned on a given host. This makes sure we > don't reuse previous addresses > B: Use logical addresses, such as java.rmi.VMID or java.rmi.server.UID, which are unique over time for a given host. > Then, it doesn't matter what ports we use because the ports are not used to determine a member's identity. > The JIRA task for logical addresses is http://jira.jboss.com/jira/browse/JGRP-129. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-971) RpcDispatcher/MessageDispatcher: additional methods which return a Future rather than blocking

by Bela Ban (JIRA)

RpcDispatcher/MessageDispatcher: additional methods which return a Future rather than blocking ---------------------------------------------------------------------------------------------- Key: JGRP-971 URL: https://jira.jboss.org/jira/browse/JGRP-971 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Currently, synchronous (cluster-wide) calls in RpcDispatcher and MessageDispatcher block until all (or a portion) of the responses have been received. Goal: to provide additional methods for callRemoteMethods() and castMessage() which return a Future<RspList>. This allows a user to dispatch multiple blocking calls and fetch the result later, e.g. (pseudo code): Future<RspList> r1, r2; r1=dispatcher.callRemoteMethods(null, "foo", new Object[]{10}, new Class[](int.class}, GroupRequest.GET_ALL, 5000); r2=dispatcher.callRemoteMethods(null, "bar", new Object[]{10}, new Class[](int.class}, GroupRequest.GET_ALL, 5000); // do something if(r1.isDone()) { RspList rsp_1=r1.getResult(); } This should be combined with a notification mechanism (RspFilter) so a users gets notified (if desired) of each response, and also when the result is complete -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JGRP-129) Logical addresses

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-129?page=com.atlassian.jira.plugi... ] Bela Ban resolved JGRP-129. --------------------------- Resolution: Done > Logical addresses > ----------------- > > Key: JGRP-129 > URL: https://jira.jboss.org/jira/browse/JGRP-129 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.9 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.8 > > > [JGroups/doc/design/LogicalAddresses.txt] > The address chosen by each node is essentially the IP address and port of the receiver socket. However, for the following reasons, this is not good enough: > - The node is shunned (excluded) and re-joins after leaving. We'd like to have the same logical address, although the physical address changed. This is already done in JBoss code, should be available in JGroups proper > - NIC failover: a NIC goes down, we want to continue sending/receiving on a different NIC > - The sender sends on all available NICs (send_on_all_interfaces="true"). This means that -if we take the receiver's datagram packet's address to be the identity of the sender - we get N different identities; 1 for each interface the message is sent on > - Network Address Translation: the sender's address might get changed by the NAT > DESIGN: > - A logical address consists of > - a user-given (or generated) name, e.g. "X". This name stays with the address from channel creation > to channel close > - a UUID. This is created on channel connect, deleted on channel disconnect and re-created on channel > connect. This is used for equals() and hashCode() of the logical address. Since it is re-created on > every connect(), it will prevent reincarnation issues. UUIDs are guaranteed to be unique over time for > a given host. This is better than using address:port, because port is not guaranteed to be unique over > time, especially when we use bind_port > - A logical address is picked, either by JGroups, or set by a user on channel creation. The lifetime of this address is the lifetime of the process in which the channel is created, or until channel.close() or disconnect() is called. > - Each member as a small cache, in which it associates the logical addresses for messages received with the sender's address. When a message is to be sent to a logical address (unicast message), the corresponding physical address is looked up from the cache. Note that there maybe multiple physical addresses if the same message was sent on different interfaces (send_on_all_interfaces="true"). > - The logical addresses must be picked such that they cannot be reused after disconnect()/close(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBBOOT-58) Split contracts of impl-as into SPI project

by Andrew Lee Rubinger (JIRA)

Split contracts of impl-as into SPI project ------------------------------------------- Key: JBBOOT-58 URL: https://jira.jboss.org/jira/browse/JBBOOT-58 Project: JBoss Bootstrap Issue Type: Task Components: impl-as, spi-as Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 0.1.2 Make a new spi-as project to house the contracts for the AS Bootstrap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBOOT-59) Create an AS Server Factory

by Andrew Lee Rubinger (JIRA)

Create an AS Server Factory --------------------------- Key: JBBOOT-59 URL: https://jira.jboss.org/jira/browse/JBBOOT-59 Project: JBoss Bootstrap Issue Type: Task Components: spi-as Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 0.1.2 Make a Factory to return JBossASServer implementations w/out needing the impl classes upon the ClassPath -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 2 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2009