[JBoss JIRA] Created: (JBMESSAGING-977) JMSRemotingConnection.setFailed() has a redundant call to org.jboss.remoting.Client.disconnect()
by Ron Sigal (JIRA)
JMSRemotingConnection.setFailed() has a redundant call to org.jboss.remoting.Client.disconnect()
------------------------------------------------------------------------------------------------
Key: JBMESSAGING-977
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-977
Project: JBoss Messaging
Issue Type: Bug
Reporter: Ron Sigal
Assigned To: Tim Fox
Priority: Minor
The call client.disconnect() occurs twice, and the first one should be removed. The result of the first call is that the subsequent call to client.removeListener(callbackManager) fails:
2007-05-25 11:52:12,956 415134 DEBUG [org.jboss.jms.client.remoting.JMSRemotingConnection] (Thread-353:) JMSRemotingConnection[bisocket://10.5.2.224:4457/?NumberOfCallRetries=10&clientMaxPoolSize=100&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&dataType=jms&marshaller=org.jboss.jms.server.remoting.JMSWireFormat&numberOfRetries=5&serializationtype=jms&socket.check_connection=false&unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat] failed to cleanly remove callback manager from the client
java.lang.Exception: Can not remove callback listener as remoting client is not connected to server.
at org.jboss.remoting.Client.removeListener(Client.java:1090)
at org.jboss.jms.client.remoting.JMSRemotingConnection.setFailed(JMSRemotingConnection.java:340)
at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:100)
at org.jboss.jms.client.container.ConnectionFailureListener.handleConnectionException(ConnectionFailureListener.java:57)
at org.jboss.jms.client.remoting.ConsolidatedRemotingConnectionListener.handleConnectionException(ConsolidatedRemotingConnectionListener.java:83)
at org.jboss.remoting.ConnectionValidator$1.run(ConnectionValidator.java:346)
--
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
18 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-927) java.io.IOException: EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment; class invalid for deserialization
by David (JIRA)
java.io.IOException: EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment; class invalid for deserialization
------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-927
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-927
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Remoting
Affects Versions: 1.2.0.GA
Environment: jboss 4.2.0CR1, java 1.5, jboss messaging 1.2.0ga
Reporter: David
Assigned To: Ovidiu Feodorov
09:58:12,495 ERROR [ServerThread] failed
java.io.IOException: EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment; class invalid for deserialization
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:571)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1634)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:479)
at EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap.readObject(ConcurrentHashMap.java:1205)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
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 org.jboss.jms.wireformat.SerializedPacket.read(SerializedPacket.java:72)
at org.jboss.jms.server.remoting.JMSWireFormat.read(JMSWireFormat.java:307)
at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:641)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:523)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:377)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:159)
09:58:14,711 WARN [Lease] Tried to terminate lease for session id 5c4o1w13-o9260j-ezjuc4ur-1-ezjuc5w1-4, but no collection of clients have been set.
09:58:14,711 WARN [Lease] Tried to terminate lease for session id null, but no collection of clients have been set.
That exception can be caused when using the jboss-messaging-client.jar that ships with the jboss-messaging release. The jboss-messaging-client.jar contains a version of EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap$Segment that implements Serializable. However, the jboss app server contains a "concurrent.jar" that has a version of ConcurrentHashMap$Segment that does not implement Serializable. Replacing the version of lib/concurrent.jar with a version of concurrent.jar that contains a ConcurrentHashMap$Segment that implements Serializable will solve this issue.
This situation occurs when you have a remote client that sends a message to a Queue.
--
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
18 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-965) JBoss Messaging client fails to reconnect after restart of the server
by pgervais (JIRA)
JBoss Messaging client fails to reconnect after restart of the server
---------------------------------------------------------------------
Key: JBMESSAGING-965
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-965
Project: JBoss Messaging
Issue Type: Bug
Reporter: pgervais
Assigned To: Tim Fox
There seem to be a clean up problem with the client JBoss Messaging QueueConnection.
When following these steps, everything works fine:
1. create a QueueConnection
2. create a QueueSender
3. send a message
4. create QueueReceiver (on the same queue as the QueueSender)
5. receive the sent message
6. close the connection
7. shutdown the JBoss server
8. restart the JBoss server
9. execute step 1-6
Everything works fine
But following these steps:
1. create a QueueConnection
2. create a QueueSender
3. send a message
4. create QueueReceiver (on the same queue as the QueueSender)
5. receive the sent message
6. shutdown the JBoss server
7. close the connection (I get an exception, it should be normal)
8. restart the JBoss server
9. execute step 1, I get an exception, this should not be normal
After investigating, I think that the problem happens when the close is executed in the second case. It seems that an exception is thrown before all the clean up has been done, because I see a thread named WorkerThread#1[142.117.14.44:3421] (which is my machine address and what seems to be the port on which the thread is listening). That thread was not present in the first case, it disappeared after executing close on the QueueConnection.
After further investigation, it seems that the problem is due to a clean up problem with the org.jboss.remoting.InvokerRegistry. The client invoker and server invoker from the previously created connection are not unregistered when the close method fails.
--
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
18 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-634) If Server is restarted, client leases IDs might be out of sync
by Clebert Suconic (JIRA)
If Server is restarted, client leases IDs might be out of sync
--------------------------------------------------------------
Key: JBMESSAGING-634
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-634
Project: JBoss Messaging
Issue Type: Bug
Reporter: Clebert Suconic
Assigned To: Ovidiu Feodorov
This is the scenario I have:
I start the server...
I have clients opening/closing connections in a loop...
I kill the server...
(will ignore the errors on client until I get restarted)
I restart the server....
I will get a bunch of errors on client, regarding not being able to find ClientIds on Lease operations (Just WARNs)
Kill the client...
after some time.. .the server gets into an unexpected state, after we have seen this exception:
20:59:37,765 ERROR [STDERR] java.lang.NullPointerException
20:59:37,765 ERROR [STDERR] at org.jboss.remoting.Lease.notifyClientLost(Lease.java:211)
20:59:37,765 ERROR [STDERR] at org.jboss.remoting.Lease.access$300(Lease.java:39)
20:59:37,765 ERROR [STDERR] at org.jboss.remoting.Lease$LeaseTimerTask.run(Lease.java:242)
20:59:37,765 ERROR [STDERR] at java.util.TimerThread.mainLoop(Timer.java:512)
20:59:37,765 ERROR [STDERR] at java.util.TimerThread.run(Timer.java:462)
I consider the description of this JIRA issue very subjective, we should rename it as soon as we have found the real cause.
--
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
18 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-923) Creating queue/topic with JNDI subcontexts fails, e.g. names such as queue/foo/bar
by Elias Ross (JIRA)
Creating queue/topic with JNDI subcontexts fails, e.g. names such as queue/foo/bar
----------------------------------------------------------------------------------
Key: JBMESSAGING-923
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-923
Project: JBoss Messaging
Issue Type: Bug
Reporter: Elias Ross
Assigned To: Ovidiu Feodorov
The following service.xml will generate an exception:
<server>
<loader-repository>
jboss.messaging:loader=ScopedLoaderRepository
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=ppm/mt"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=Se
rverPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
</server>
15:46:12,205 ERROR [ExceptionUtil] Queue[/queue/ppm/bridge/mqube, name=ppm/bridg
e/mqube] startService
javax.naming.NameNotFoundException: ppm not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
at org.jnp.server.NamingServer.rebind(NamingServer.java:165)
at org.jnp.server.NamingServer.rebind(NamingServer.java:168)
at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:510)
at org.jnp.interfaces.NamingContext.rebind(NamingContext.java:477)
at org.jboss.jms.server.DestinationJNDIMapper.registerDestination(Destin
ationJNDIMapper.java:146)
at org.jboss.jms.server.destination.QueueService.startService(QueueServi
ce.java:142)
--
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
18 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-553) Run AS (4.x and 5.x) integration tests with Messaging
by Ovidiu Feodorov (JIRA)
Run AS (4.x and 5.x) integration tests with Messaging
-----------------------------------------------------
Key: JBMESSAGING-553
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-553
Project: JBoss Messaging
Issue Type: Task
Components: Tests and Performance
Reporter: Ovidiu Feodorov
Assigned To: Richard Achmatowicz
Priority: Critical
Fix For: 1.2.0.Beta1
This is the container task for everthing required to run JBoss AS JMS integration tests with JBoss Messaging. The existing integration test framework should be modified in such a manner to allow interchangeably running the same JMS tests with JBossMQ and JBoss Messaging. None of the existing JBossMQ tests should be removed, they must be at most refactored so the JBossMQ-specific tests will be executed with JBossMQ only (as part of the JBossMQ functional testsuite) and generic JMS tests will be executed with both JBossMQ and JBoss Messaging.
More details in the sub-tasks.
--
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
18 years, 10 months
[JBoss JIRA] Created: (JGRP-384) DistributedLockManager.unlock() throws an exception if one of the group members terminates.
by Sean Landis (JIRA)
DistributedLockManager.unlock() throws an exception if one of the group members terminates.
-------------------------------------------------------------------------------------------
Key: JGRP-384
URL: http://jira.jboss.com/jira/browse/JGRP-384
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Suse Linux 10.1 Desktop
java version "1.5.0_07"
Dell Optiplex GX280
Reporter: Sean Landis
Assigned To: Bela Ban
I am trying to use the DLM to implement a failover mechanism. Two
identical processes are started. One acquires the lock and becomes the
primary; the other can't acquire the lock and becomes the backup. The
primary does it's processing. The backup checks periodically if it can
get the lock. Should the primary fail, the backup will acquire the
lock and do the processing.
This works fine. The problem I am having is if both are running, the
backup fails, and the primary tries to unlock. I get the following
stack trace:
Exception in thread "main"
org.jgroups.blocks.LockNotReleasedException: Lock cannot be unlocked.
at org.jgroups.blocks.DistributedLockManager.unlock(DistributedLockManager.java:318)
at org.jgroups.blocks.DistributedLockManager.unlock(DistributedLockManager.java:260)
at com.overstock.distlock.examples.FailoverTest.doIt(FailoverTest.java:50)
at com.overstock.distlock.examples.FailoverTest.main(FailoverTest.java:61)
I am running version 2.4. Here's a sample program:
package distlock.examples;
import org.jgroups.JChannel;
import org.jgroups.blocks.DistributedLockManager;
import org.jgroups.blocks.LockNotGrantedException;
import org.jgroups.blocks.VotingAdapter;
public class FailoverTest {
public static final String SERVER_PROTOCOL_STACK =
"UDP(mcast_addr=228.3.11.76;mcast_port=12345;ip_ttl=1;"
+ "mcast_send_buf_size=150000;mcast_recv_buf_size=80000)"
+ ":PING(timeout=500;num_initial_members=1)"
+ ":FD"
+ ":VERIFY_SUSPECT(timeout=1500)"
+ ":pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800)"
+ ":UNICAST(timeout=5000)"
+ ":pbcast.STABLE(desired_avg_gossip=200)"
+ ":FRAG(frag_size=4096)"
+ ":pbcast.GMS(join_timeout=5000;join_retry_timeout=1000;"
+ "shun=false;print_local_addr=false)"
;
private void doIt() throws Exception {
JChannel channel = new JChannel(SERVER_PROTOCOL_STACK);
VotingAdapter adapter = new VotingAdapter(channel);
channel.connect("cluster");
DistributedLockManager dlm = new DistributedLockManager(adapter, "Mgr");
String lockId = "theLock";
for (int i = 0; i < 40; i++) {
while (true) {
try {
System.out.println("Trying to get lock.");
dlm.lock(lockId, channel.getLocalAddress(), 10000);
break;
} catch (LockNotGrantedException ex) {
System.out.println("Could not get lock.");
}
try {
Thread.sleep(5000);
} catch(InterruptedException ex) {
}
}
System.out.println("Got lock, sleeping.");
try {
Thread.sleep(10000);
} catch(InterruptedException ex) {
}
System.out.println("unlocking and sleeping.");
dlm.unlock(lockId, channel.getLocalAddress());
try {
Thread.sleep(5000);
} catch(InterruptedException ex) {
}
}
channel.close();
}
public static void main(String[] args) throws Exception {
System.setProperty("java.net.preferIPv4Stack", "true");
new FailoverTest().doIt();
}
}
--
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
18 years, 10 months