[Design the new POJO MicroContainer] - Re: ClassPool for JBoss Reflection
by flavia.rainone@jboss.com
"kabir.khan(a)jboss.com" wrote : The classpools from asintegration-mc could be put into another jar, although I am not sure if jboss-reflect is the right place for them. Maybe they should be put into another project.
This is a question whose answer I don't know. I thought it belonged to JBoss Reflect, as there is a task to create an appropriate class loader (JBREFLECT-3). Isn't those class pools all that is needed to make JBoss Reflect/Javassist to work on the AS environment?
"kabir.khan(a)jboss.com" wrote : Also, due to the workings of AOP, they extend AOPClassPool from the aop project, which in turn extends ScopedClassPool from javassist.
|
| Ideally we should have one jar for the classpool from aop, one for the classpool from asintegration-core, one for the one from asintegration-jmx and one for asintegration-mc.
|
| AOPClassPool and the ClassPoolFactories have some dependencies on the AspectManager, but it should be possible to abstract that out.
Yes, I can refactorate that, and extract the dependencies to a ClassPool wrapper, if we decide to go this way.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237745#4237745
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237745
16 years, 9 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Deadlock on pinger (recent commit)
by clebert.suconic@jboss.com
The latest commit on Pinger introduced a deadlock. It looks like easy to fix though.
| Java stack information for the threads listed above:
| ===================================================
| "Thread-4 (group:JBM-scheduled-threads-331781542)":
| at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.exceptionCaught(MessagingChannelHandler.java:103)
| - waiting to lock <0x00007f7488dc0610> (a org.jboss.messaging.integration.transports.netty.NettyAcceptor$MessagingServerChannelHandler)
| at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:147)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
| at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
| at org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.java:206)
| at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:129)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
| at org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:607)
| at org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:577)
| - locked <0x00007f7488dc0848> (a java.lang.Object)
| at org.jboss.netty.channel.socket.nio.NioWorker.write(NioWorker.java:326)
| at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:140)
| at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:79)
| at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:791)
| at org.jboss.netty.channel.SimpleChannelHandler.writeRequested(SimpleChannelHandler.java:309)
| at org.jboss.netty.channel.SimpleChannelHandler.handleDownstream(SimpleChannelHandler.java:271)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:590)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:585)
| at org.jboss.netty.channel.Channels.write(Channels.java:878)
| at org.jboss.netty.channel.Channels.write(Channels.java:826)
| at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:236)
| at org.jboss.messaging.integration.transports.netty.NettyConnection.write(NettyConnection.java:128)
| at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.send(RemotingConnectionImpl.java:1056)
| - locked <0x00007f7488dc1ce0> (a java.lang.Object)
| at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.send(RemotingConnectionImpl.java:1006)
| at org.jboss.messaging.core.remoting.impl.Pinger.run(Pinger.java:122)
| - locked <0x00007f7487faaef8> (a org.jboss.messaging.core.remoting.impl.Pinger)
| at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
| at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
| at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
| 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)
| "New I/O server worker #1-1":
| at org.jboss.messaging.core.remoting.impl.Pinger.close(Pinger.java:130)
| - waiting to lock <0x00007f7487faaef8> (a org.jboss.messaging.core.remoting.impl.Pinger)
| at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl.closeConnection(RemotingServiceImpl.java:399)
| at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:319)
| at org.jboss.messaging.integration.transports.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:458)
| at org.jboss.messaging.integration.transports.netty.MessagingChannelHandler.channelDisconnected(MessagingChannelHandler.java:85)
| - locked <0x00007f7488dc0610> (a org.jboss.messaging.integration.transports.netty.NettyAcceptor$MessagingServerChannelHandler)
| at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:137)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
| at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:803)
| at org.jboss.netty.handler.codec.frame.FrameDecoder.cleanup(FrameDecoder.java:304)
| at org.jboss.netty.handler.codec.frame.FrameDecoder.channelDisconnected(FrameDecoder.java:194)
| at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:119)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:567)
| at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:562)
| at org.jboss.netty.channel.Channels.fireChannelDisconnected(Channels.java:496)
| at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:520)
| at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:321)
| at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:307)
| at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
| at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
| at org.jboss.netty.util.internal.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:72)
| at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
| 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)
|
| Found 1 deadlock.
|
|
I'm removing the synchronized on Pinger.close at my copy just to get the testsuite running. I will post the results here later today.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237718#4237718
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237718
16 years, 9 months
[Design of JBoss Identity] - local tx transaction or xa transaction datasource?
by jeff.yuchang
In the JBoss idm distribution deployment. I am using the xa datasource as default, like following one as mysql one.
| <?xml version="1.0" encoding="UTF-8"?>
| <datasources>
|
| <xa-datasource>
| <jndi-name>jbossidmDS</jndi-name>
|
| <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
| <xa-datasource-property name="URL">@jdbc.url@</xa-datasource-property>
| <user-name>@jdbc.username@</user-name>
| <password>@jdbc.password@</password>
|
|
| <!-- reduce isolation from the default level (repeatable read) -->
| <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
| <!-- separate connections used with and without JTA transaction -->
| <no-tx-separate-pools />
| <!-- disable transaction interleaving -->
| <track-connection-by-tx />
|
| <!-- leverage mysql integration features -->
| <exception-sorter-class-name>
| com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
| </exception-sorter-class-name>
| <valid-connection-checker-class-name>
| com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker
| </valid-connection-checker-class-name>
|
| <!-- corresponding type-mapping in conf/standardjbosscmp-jdbc.xml -->
| <metadata>
| <type-mapping>mySQL</type-mapping>
| </metadata>
| </xa-datasource>
|
| </datasources>
|
Was wondering is it better that we used the local-tx datasource as default, or use the xa-datasource as now.
What do you think?
Thanks
Jeff
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237700#4237700
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237700
16 years, 9 months