[JBoss JIRA] Created: (JBREM-762) Deadlock bug in socket invoker
by Tim McCune (JIRA)
Deadlock bug in socket invoker
------------------------------
Key: JBREM-762
URL: http://jira.jboss.com/jira/browse/JBREM-762
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 1.4.6.GA
Environment: JBoss 4.0.4 EJB 3.0-rc9-patch1 JDK 1.6.0
Reporter: Tim McCune
There is a potential thread leak in ServerThread.java that causes ServerThreads to stick around, but to disappear from the thread pool as the accept() thread(s) see it. Eventually, when the # of leaked threads reaches the MaxPoolSize, the system ends up deadlocked and will not accept any more incoming socket connections. I have described the problem in great detail in a forum post and in support case 00016786. I have patched the code, and so far it seems to be working fine and to have fixed the problem. This is what I patched:
In ServerThread.java, I wrapped the contents of wakeup() inside of a try/catch, block, with the following code in the catch block:
} catch (Exception e) {
synchronized (clientpool) {
synchronized (threadpool) {
clientpool.remove(this);
threadpool.add(this);
Thread.interrupted();
}
}
throw e;
}
This makes sure that the thread is put back into the threadpool when an exception occurs in the createServerSocket() method (this method is doing socket I/O in 1.4.6, and in our case, this socket connection was timing out.).
--
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
12 years, 5 months
[JBoss JIRA] Created: (JBREM-652) allow passing of config map when creating transporter client
by Tom Elrod (JIRA)
allow passing of config map when creating transporter client
------------------------------------------------------------
Key: JBREM-652
URL: http://jira.jboss.com/jira/browse/JBREM-652
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: transporter
Affects Versions: 2.2.0.Alpha4
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.2.0.Beta1 (Bluto)
Currently the transporter client can only be created using invoker locator for configuration. Need to add to the api so can pass config map which gets passed to the remoting client that is created so can customize things such as ssl config. For example, would be need to be able to something like is done in org.jboss.test.remoting.transport.socket.ssl.custom.InvokerClientTest with a transporter client.
--
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
12 years, 5 months
[JBoss JIRA] Created: (JBREM-738) ServerThread/invoker still executing invocation after its related TransportServer was stopped
by craig bordelon (JIRA)
ServerThread/invoker still executing invocation after its related TransportServer was stopped
---------------------------------------------------------------------------------------------
Key: JBREM-738
URL: http://jira.jboss.com/jira/browse/JBREM-738
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transporter
Affects Versions: 2.2.0.Beta1 (Bluto)
Environment: java 1.5 on solaris but doubt its specific to this one.
Reporter: craig bordelon
Assigned To: Tom Elrod
get an exception on the third iteration of a transporter client to a transporter server where the client code is doing the same invoke each time. This should not happen as the first two iterations give correct result. The exception is thrown from the server side as apparently the jboss remoting internals are confused -- stating that a ServerInvoker is not in "started state".
Exception is
java.lang.reflect.UndeclaredThrowableException
at $Proxy4.toString(Unknown Source)
at java.lang.String.valueOf(String.java:2615)
at java.lang.StringBuilder.append(StringBuilder.java:116)
at proxy.Client.testClientCall(Client.java:38)
at proxy.Client.main(Client.java:115)
Caused by: org.jboss.remoting.ServerInvoker$InvalidStateException: Can not proc
ess invocation request since is not in started state.
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:751)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(S
erverThread.java:568)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.
java:390)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.ja
va:164)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClient
Invoker.java:163)
at org.jboss.remoting.Client.invoke(Client.java:1548)
at org.jboss.remoting.Client.invoke(Client.java:534)
at org.jboss.remoting.Client.invoke(Client.java:522)
at org.jboss.remoting.transporter.TransporterClient.invoke(TransporterC
lient.java:297)
to reproduce this (one way at least):
run the transporter sample modified for the Client to execute the the makeClientCall multiple times.
Now
to get past the obvious first issue (socket in use) add new code for
customerProcessor.releaseCustomer(processedCustomer.getCustomerId()
in the Client just before the
TransporterClient.destroyTransporterClient(customerProcessor);
Implement this method in the CustomerProcessorImpl to use the id to locate (eg hash get()) the related ICustomer TransporterClient and destroy it and to the TransporterServer to stop it.
This theoretically frees up the Customer "server" allowing for the next iteration by the Client.
note that the processCustomer() implemenation is modified to store the TransporterClient and TransporterServer that are created here.
------------
I dug into the code a bit and what i gathered is that a ServerThread is trying to do processInvocation using a SocketServerInvoker that was already "stopped". I think the ServerThread itself should not be executing as the TransporterServer it should be involved with was already stopped.
I posted to the jboss forum on issues i was having trying to make the transporter sample run from the client multiple times. See issue by "bord" on 4/17/2007
--
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
12 years, 5 months
[JBoss JIRA] Created: (JBREM-591) Make asynchronous calls using Transporter
by vivek v (JIRA)
Make asynchronous calls using Transporter
-----------------------------------------
Key: JBREM-591
URL: http://jira.jboss.com/jira/browse/JBREM-591
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: transporter
Reporter: vivek v
Assigned To: Tom Elrod
This came out of the user forum question,
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89224
Currently, there is a mechanism to do asynchronous calls and callbacks using InvocationHandler. As more and more people are using POJOs (via Transporter) for remoting it would be great if we can have the same features (both asynchronous calls and callbacks) available for the Transporter.
Couple of use cases can be,
Asynchronous Call
-----------------------------
1) Client makes a simple method call (using POJO) on server
2) Server gets the request and returns immediately to the Client. Now Client is free to do its own stuff without waiting or polling for the result.
3) Server starts processing the request
4) When the response is ready Server sends the response to the Client.
Callbacks
--------------------
1) An alert happens on the server side
2) Server should be able to send the alert to the Client without Client requesting for it.
--
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
12 years, 5 months
[JBoss JIRA] Created: (JBREM-585) there is the need to add a callback listener for ssl stream invocation
by Michael Voss (JIRA)
there is the need to add a callback listener for ssl stream invocation
----------------------------------------------------------------------
Key: JBREM-585
URL: http://jira.jboss.com/jira/browse/JBREM-585
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: stream
Affects Versions: 2.0.0.CR1 (Boon)
Reporter: Michael Voss
Assigned To: Tom Elrod
Fix For: 2.0.0.GA (Boon)
If want to use existing ssl connector for stream invocation (using Client.invoke(InputStream,Object,Connector) ) the client has to add a callback listener to run the the invocation properly
I think stream invocation should also work without the need to add a callback listener
if no listener is added the following exception is thrown:
by stream sender:
org.jboss.remoting.ConnectionFailedException: Connection has been shutdown: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1
at org.jboss.remoting.transport.multiplex.MultiplexClientInvoker.handleConnect(MultiplexClientInvoker.java:111)
at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:252)
at org.jboss.remoting.Client.connect(Client.java:391)
at org.jboss.remoting.Client.connect(Client.java:383)
at org.jboss.remoting.stream.StreamHandler.<init>(StreamHandler.java:77)
at org.jboss.remoting.ServerInvoker.getStreamHandler(ServerInvoker.java:1253)
at org.jboss.remoting.ServerInvoker.handleInternalInvocation(ServerInvoker.java:1225)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:983)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:447)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:520)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:257)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
at org.jboss.remoting.Client.invoke(Client.java:612)
at org.jboss.remoting.Client.invoke(Client.java:604)
at org.jboss.remoting.Client.invoke(Client.java:1211)
by stream receiver:
javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLProto
colException: Illegal client handshake msg, 1
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(Unknown Source)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn
putThread.completeHeader(InputMultiplexor.java:608)
at org.jboss.remoting.transport.multiplex.InputMultiplexor$SingleGroupIn
putThread.doRun(InputMultiplexor.java:540)
at org.jboss.remoting.transport.multiplex.utility.StoppableThread.run(St
oppableThread.java:54)
Caused by: javax.net.ssl.SSLProtocolException: Illegal client handshake msg, 1
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown
Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source
)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Un
known Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source
)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)
at java.io.OutputStream.write(Unknown Source)
at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread
.encode(OutputMultiplexor.java:580)
at org.jboss.remoting.transport.multiplex.OutputMultiplexor$OutputThread
.doRun(OutputMultiplexor.java:452)
... 1 more
--
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
12 years, 5 months
[JBoss JIRA] Created: (EJBTHREE-1343) Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server
by Dimitris Andreadis (JIRA)
Remove the cyclical dependency from ejb3/core to org.jboss.jbossas-jboss-as-server
----------------------------------------------------------------------------------
Key: EJBTHREE-1343
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1343
Project: EJB 3.0
Issue Type: Task
Components: core
Reporter: Dimitris Andreadis
Assigned To: Carlo de Wolf
Priority: Critical
Fix For: AS 5.0.0.CR1
ejb3/core -> jboss-as-server dependencies
------------------------------------------------------------
ejb3/core
./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.corba.ORBFactory
------------------------------------------------------------
ejb3/core
./org/jboss/ejb3/naming/client/java/javaURLContextFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.naming.client.java.HandleDelegateFactory;
------------------------------------------------------------
ejb3/core
./org/jboss/ejb3/AllowedOperationsInterceptor.java
./org/jboss/ejb3/service/ServiceContainer.java
./org/jboss/ejb3/stateless/StatelessContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.AllowedOperationsAssociation
ejb3/core
./org/jboss/ejb3/mdb/MessagingContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.jms.jndi.JMSProviderAdapter;
org.jboss.jbossas:jboss-as-server
-----------------------------------------
ejb3/core
./org/jboss/ejb3/timerservice/jboss/JBossTimerServiceFactory.java
./org/jboss/ejb3/timerservice/TimedObjectInvoker.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.txtimer.EJBTimerService;
org.jboss.ejb.txtimer.TimedObjectInvoker
-----------------------------------------
ejb3/core
./org/jboss/ejb3/stateful/StatefulLocalProxyFactory.java
./org/jboss/ejb3/stateless/StatelessContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.proxy.ejb.handle.StatefulHandleImpl;
org.jboss.proxy.ejb.handle.HomeHandleImpl;
------------------------------------------
ejb3/core
./org/jboss/ejb3/AllowedOperationsInterceptor.java
./org/jboss/ejb3/ContainerPlugin.java
./org/jboss/ejb3/service/ServiceContainer.java
./org/jboss/ejb3/stateless/StatelessContainer.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.AllowedOperationsFlags
-------------------------------------------
ejb3/core
./org/jboss/ejb3/EJBProxyFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.invocation.Invocation
--------------------------------------------
ejb3/core
./org/jboss/ejb3/EJBProxyFactory.java
depends on org.jboss.jbossas:jboss-as-server
org.jboss.ejb.GenericEntityObjectFactory
--
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
12 years, 5 months
[JBoss JIRA] Created: (JGRP-726) GossipRouter: support GET and REGISTER via UDP datagram packets
by Bela Ban (JIRA)
GossipRouter: support GET and REGISTER via UDP datagram packets
---------------------------------------------------------------
Key: JGRP-726
URL: http://jira.jboss.com/jira/browse/JGRP-726
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.8
Currently, GossipRouter supports only TCP. If a GossipClient calls register() or getMembers(), then a TCP connection is established and torn down after the request. This is inefficient and leads to many sockets in TIME_WAIT states (which are cleaned up after 2 * MSL seconds).
If we (in GossipRouter) add an additional listener, which listens on a UDP port, and provide the same for GossipClient, we would not use precious TCP sockets.
Think about: we should separate the transport in GR from the processing logic, so we could support TCP, UDP, HTTP etc. Should we use JGroups (in unicast mode) for this ?
--
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
12 years, 5 months