[jboss-user] [JBossCache] - Patch adding transactional putSilent() method
Please, can you review this patch for addition into the mainline JBoss Cache? The motivation for this patch Currently, JBoss Cache adapter for Hibernate uses putForExternalRead() method. This method suspends and then resumes the current transaction and this is slow with some transaction managers, particularly with ones that support transaction recovery. For example, with Atomikos Transaction Manager it takes 25 seconds with putForExternalRead() on my computer to load a big Hibernate model versus 3 seconds with simple put() method in org.hibernate.cache.Cache implementation. But simple put() method can't be used reliably, because DataVersioningException will be thrown if another thread has loaded the same object and put it in the cache. Patch details I've developed this patch to solve this problem. It adds putSilently() method to Cache interface, this method works exactly like putForExternalRead() except that it does not suspend and resume the current transaction. Instead, workspace nodes are marked so they can be ignored during optimistic validation if it fails. I don't have much experience with JBoss Cache, but this patch works for me (or at least looks like it is working :) ). If the general idea is OK, I'll add mode documentation and unit tests for inclusion into the official JBoss Cache package. You can get the patch here: http://sd-sup.staffdirector.net/cache.patch View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4082353#4082353 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4082353 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - putForExternalRead very slow
I'm using JBoss Cache with Atomikos Transaction Manager and putForExternalRead method is VERY slow (about 20 times slower than 'put') because it has to suspend and resume the current transaction (and this is not a cheap operation in Atomikos). Is it possible to have transactional 'put' which simply swallows DataVersioningExceptions without rolling back the transaction and without attempting to suspend/resume transaction? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4081640#4081640 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4081640 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Remoting] - Possible failure mode?
As far as I understand, JBoss Remoting has the following failure mode. Suppose we have a client which connects to JBoss using HTTP/Servlet connector (I don't know about other connectors, possibly they have the same failure mode). Now let's suppose that client has sent request to server, server has received this request and started its processing. What happens if client is disconnected while request is being processed? Client has no way to know that request processing has started. How this situation can be resolved? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4022238#4022238 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4022238 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Security JAAS/JBoss] - Re: Concurrency bug in JaasSecurityManager
[EMAIL PROTECTED] wrote : Also note that there is no reliance on shared subjects in the server post 4.0.3SP1 so the details of where you believe a shared subject is in use are needed. | Strange, I'm using jboss-4.0.5.GA (build from source package). It definitely relies on shared subjects. The version tag from JaasSecurityManager.java: anonymous wrote : | @version $Revision: 57203 $ | BTW, there's also another small bug in JaasSecurityManager.java - no check for null 'domainCache' in getPrincipal() method. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3992473#3992473 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3992473 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Security JAAS/JBoss] - Re: Redeployment of JaasSecurityContext fails
Is there any fundamental reason why it is not meant to be redeployed? I tried to change this parameter to 'true', now JaasSecurityContext can be redeployed but my application throws ClassCastExceptions. I know that this is a classloader issue and I'm planning to investigate and possibly fix it if is possible without huge effort. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3992475#3992475 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3992475 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Security JAAS/JBoss] - Re: Concurrency bug in JaasSecurityManager
It doesn't perform deep copy of Subjects, so the copied subject shares its role collection with the original subject. Deep copy is controlled by the flag which is never set to 'true': | /** The flag to indicate that the Subject sets need to be deep copied*/ |private boolean deepCopySubjectOption = false; | View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3992479#3992479 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3992479 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Security JAAS/JBoss] - Re: Concurrency bug in JaasSecurityManager
Yes, that solves the problem. I was worried that this setting can break something subtle (because it is undocumented). So I choose to ask here. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3992491#3992491 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3992491 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Security JAAS/JBoss] - Re: Redeployment of JaasSecurityContext fails
Bump. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3992394#3992394 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3992394 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB/JBoss] - HttpInvoker for EJBs on 4.0.5GA doesn't work
HttpInvoker on 4.0.5GA doesn't correctly marshal exceptions from EJB methods.
I'm getting this exception:
| org.jboss.remoting.CannotConnectException: Can not connect http client
invoker.
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
| at
org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
| at org.jboss.remoting.Client.invoke(Client.java:525)
| at org.jboss.remoting.Client.invoke(Client.java:488)
| at
org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
| at $Proxy1.getPossibleFAs(Unknown Source)
| at com.sd.sdmain.gui.login.LoginDialog$5.run(LoginDialog.java:163)
| at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
| at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
| at java.util.concurrent.FutureTask.run(FutureTask.java:123)
| at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65)
| at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168)
| at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.io.StreamCorruptedException: invalid stream header
| at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:753)
| at java.io.ObjectInputStream.init(ObjectInputStream.java:268)
| at
org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.init(ObjectInputStreamWithClassLoader.java:73)
| at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:52)
| at
org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:119)
| at
org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
| at
org.jboss.remoting.marshal.http.HTTPUnMarshaller.read(HTTPUnMarshaller.java:131)
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:175)
| ... 23 more
|
on the CLIENT when I'm throwing from server method (or receive
EJBAccessException from JBoss). All necessary class definitions are available
on the client.
I've tried to change serialization type from java to jboss:
|mbean code=org.jboss.remoting.transport.Connector
|
name=jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3
| dependsjboss.aop:service=AspectDeployer/depends
| !--attribute
name=InvokerLocatorsocket://${jboss.bind.address}:3873/attribute--
| attribute
name=InvokerLocator${custom.server.connector}://${custom.server.host}:${custom.server.port}/servlet-invoker/ServerInvokerServlet?serializationtype=jboss/attribute
|
| attribute name=Configuration
| handlers
| handler
subsystem=AOPorg.jboss.aspects.remoting.AOPRemotingInvocationHandler/handler
| /handlers
| /attribute
|/mbean
|
But now I get ANOTHER exception:
| org.jboss.remoting.CannotConnectException: Can not connect http client
invoker.
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
| at
org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
| at
org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
| at org.jboss.remoting.Client.invoke(Client.java:525)
| at org.jboss.remoting.Client.invoke(Client.java:488)
| at
org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
| at
org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
[jboss-user] [Security JAAS/JBoss] - Redeployment of JaasSecurityContext fails
Redeployment of JaasSecurityContext on JBoss4.0.5GA fails because of line JaasSecurityManagerService.java:435: | // Register the JAAS CallbackHandler JACC PolicyContextHandlers | CallbackHandlerPolicyContextHandler chandler = new CallbackHandlerPolicyContextHandler(); | PolicyContext.registerHandler(CallbackHandlerPolicyContextHandler.CALLBACK_HANDLER_KEY, | chandler, false); | The last 'false' parameter means that Java will throw exception during redeployment, because callback handler must be replaced (and this 'false' parameter forbids replacing). What is the reason for this setting value? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3989934#3989934 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3989934 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Security JAAS/JBoss] - Concurrency bug in JaasSecurityManager
I've found a VERY curious concurrency bug in JaasSecurityManager. I'm using custom login modules and custom principal and a custom SecurityInterceptor for JNDI lookups, this interceptor checks . My DefaultCacheTimeout value was set to 0 (I wanted to turn off authentication cache). My application (remote Swing client) worked fine as long as there was only one thread doing JNDI lookups. But sometimes a second application threw exception during JNDI authorization, it turned out that authenticated Subject had an empty role set. But this is impossible, because my Subjects always have at least one role. After few hours of debugging I've found the problem: my custom login module removes its Subject roles during the logout() method. I've found that this module is called by JaasSecurityManager$DomainInfo.destroy. And that's a bug. Suppose we have two threads: | Thread 1: Thread 2 (some time after Thread1): | 1. 'User1' authentication1. 'User1' logs in. | 2. 'User1' is added to auth cache2. Auth cache entry has expired. | 3. Doing some lengthy operation 3. Calling .logout() on stale entry | 4. Checking roles of User1 - WILL FAIL, another thread has called logout()! | This problem may be not evident with the stock JBoss login modules, because their logout() methods do not remove subject's roles. Proposed fixes: 1. Use deep cloning. That way threads 1 and 2 doesn't share any data, thus no problem. 2. Use acquire/release semantics in conjunction with SecurityAssociation. 3. Remove logout() from DomainInfo.destroy. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3988690#3988690 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3988690 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
