April 2008 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Inefficiencies in JBM 2 remoting layer

by timfox

The work required here actually overlaps with work I'm currently doing on splitting up messages into chunks, so I'd like to complete it as part of that work. Unfortunately I'm going on holiday next week, so probably won't be able to get it finished until after then. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143634#4143634 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143634

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: AIO/DirectIO Integration

by timfox

"clebert.suconic(a)jboss.com" wrote : | And also, I've found some problem with reclaiming files. The counter doesn't work properly in some situation when the commit is sent to another file. I didn't fully understand the counting, but it looks like there is a problem on the ref count. | | Can you be more specific? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143632#4143632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143632

18 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Inefficiencies in JBM 2 remoting layer

by timfox

I've been looking through our current JBM 2.0 remoting layer - which uses MINA to get a good picture of how things hang together, and it strikes me there are some serious inefficiencies / redundancy in the current implementation. We are using DemuxingProtocolEncoder/Decoder - and MessageEncoder/Decoder instances - this is redundant - we should just be using ProtocolEncoder and CumulutaveProtocolDecoder directly. The DemuxingProtocolDecoder will cause decodable to be invoked on *gulp* every codec for every packet. The current decodable() implementation is very slow since it parses the packet, including parsing strings which involves allocation of new strings too, just to find out if the packet is decodable. I suspect this is why we were seeing very low performance although we know MINA can give great performance. All this is unnecessary if we just use one codec and a switch statement to identify the packet type, and just use CumulativeProtocolDecoder directly. It will also simplify the code quite a bit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143626#4143626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143626

18 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - JBoss SOA Platform

by ar.mohseni

hi to all i download jboss-soa-p.4.2.0.zip file but i dont khow username and password to login esb console. tanx View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143615#4143615 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143615

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: LogConfigurationException from commons-logging

by bstansberry＠jboss.com

Hmm, thought I'd replied before, but don't see the reply. Anyway, pretty sure you were on the right track. Log from last night's run showed a similar problem, but root cause was an ISE from BaseClassLoader when trying to use it after it had been undeployed -- i.e. a CL leak to a JGroups thread pool thread. I think this started intermittently popping up when I set "loopback=true" on the channel configs to correct the FLUSH issues you were seeing. All your fault. ;-) With loopback enabled, app threads with the app's TCCL not only push messages down the stack, they also handle carrying the message back up and passing it off to the multiplexer thread pool. If the pool allocates a new thread to handle that message, the app's TCCL leaks to the pool. I replaced the mulitplexer with the shared transport this evening; I think that should take care of this. Posted on jgroups-dev to check for other similar scenarios: http://www.nabble.com/Classloader-leaks-in-thread-pools-to16642502.html I'm working to get it so the standard JEE distributed caches are lazy initialized. That means some user deployment's TCCL is going to be in effect when cache and associated channel are created. Your post makes me realize I need to be sure to set the TCCL to the default domain loader before creating any cache or channel. Thanks. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143613#4143613 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143613

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss Portlet Container integration into 2.7

by julien＠jboss.com

I am looking at the encoder/decoder thing, it's not trivial. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143584#4143584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143584

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss Portlet Container integration into 2.7

by julien＠jboss.com

what needs to be done in the short term: 1/ extend encoder/decoder to implement resource serving urls 2/ extend encoder/decoder to implement public navigational state changes 3/ extends PortalObjectCommandFactory and PortalObjectURLFactory to take in account the InvokePortletWindowResourceCommand 4/ implement handling of resource invocation response in InvokeWindowCommand and return a StreamResponse to the controller. with that we should have support for resource serving and basic support for page render parameters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143575#4143575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143575

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - JBoss Portlet Container integration into 2.7

by julien＠jboss.com

I worked on the integration of the portlet controller, here is the status: - InvokePortletWindowActionCommand and InvokePortletWindowRenderCommand are implemented - the different controller context are implemented but do not implement coordination except that there is a basic support for public render parameter support using the page scope. - added an InvokePortletWindowResourceCommand that will serve resources. - I forked the PortletRequestEncoder and PortletRequestDecoder classes and their test case in order to extend them for resource serving and public render param. They will be removed from the portlet module later as they are not used anymore. - I started some integration of the JBPC samples in the core-samples module. For some reason of the 2 google portlet does not work (??). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143574#4143574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143574

18 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: Why do we need a security context to access a local ejb?

by anil.saldhana＠jboss.com

The PreSecurityInterceptor establishes the correct SC for both the local and remote invocations. The reason BaseLocalProxyFactory does not do any runas processing is because the SecurityContext that is set on the threadlocal (I call it the SecurityContextAssociation) is available to the PreSecurityInterceptor since the call emanated in the same vm. The proxy/SecurityInterceptor can be in the client vm. So I pick up the run as and send it in the SC over the invocation. This is a new feature (passing RunAs across VMs even though we have to attach additional trust semantics to inter-vm calls). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143545#4143545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143545

18 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: Why do we need a security context to access a local ejb?

by adrian＠jboss.org

The problem I found was no SecurityContext. But what about the case when there is one? What happens to the runAS? The BaseLocalProxyFactory should be consistent with the org.jboss.proxy.SecurityInterceptor unless I'm missing something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143538#4143538 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143538

18 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008