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

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by pete.muir＠jboss.org

anonymous wrote : This doesn't make sense, as it's completely different resources handling strategy. Sure, it doesn't make sense to *you*, but this is exactly the way any end user will see it - "Why does JBoss 5 take ~4s to open an inputstream!!!!????" ;-) It would be naive to assume that applications don't open files (let alone third party frameworks), and it's not viable to tell them "use VFS", not least because it's not a standard... Do I make sense? Or am I missing an important piece of the puzzle? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184782#4184782 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184782

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by alesj

"pete.muir(a)jboss.org" wrote : I think it would also be an idea to get an idea of how long getting a URL in JBoss 4 takes for comparison This doesn't make sense, as it's completely different resources handling strategy. JBoss4 (more of a guess, since I didn't do it and never really looked how it's done): It copies every jar into temp. Same with nested. But when it references those jars, it returns URLs with the temp paths. JBoss5: Impl details are VFS based: - deployment - metadata - classloading - ... All these pieces work on the same VFS roots. Once something is unpacked/read-in-memory, the references are kept internally, hence the same instances will work on the same (temp) files / memory. But the returned URLs are not exposing impl details == no pointing to temp files. I'll open a MC dev discussion on this URL+VFS issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184779#4184779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184779

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by mstruk

"pete.muir(a)jboss.org" wrote : | | I think Shane and you/Marko got your wires crossed, and his latter comments are regarding runtime not deployment performance. | | From: | | anonymous wrote : It does get called a lot from javax.faces.application.ViewHandler.renderView() - there are 524 invocations of org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream(). | | Shane is talking about runtime performance (when rendering a view) NOT about deployment :-) Yeah, but no harm done - we need to fix both cases anyway. And I'm glad to see the culprit is integration, and not VFS code itself :) - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184776#4184776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184776

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by ataylor

Also I wasn't sure on you're testing strategy so I've yet to add any tests. Let me know what kind of tests you prefer and write some. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184775#4184775 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184775

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by ataylor

Ive got the main mechanics of the message model and codecs done. Ive also added a couple of examples, one that sends a request to the jboss netty page and a client/server example that sends a basic string message. There are lots of bells and whistles still to be added but i thought for JBM 2.0 we probably only need the basic implementation for now. Also, I'm not yet dealing with keep-alive vs close after a request. Trustin, can you review what ive done so far and then we can discuss what is needed next. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184773#4184773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184773

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by pete.muir＠jboss.org

I think it would also be an idea to get an idea of how long getting a URL in JBoss 4 takes for comparison - Shane, could you run those numbers :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184771#4184771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184771

16 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by alesj

The question here is what can we move directly on VFS? Since if we can get a hold of existing VFS deployment root, things are gonna be fast. e.g. ServletContext --> VFSDeploymentUnit --> VFS root But like I already said, if VFS always goes via URL --> URLConnection --> VFS, then it's gonna be slow as it has no memory of previously exploded jars/entries. Keeping this info around is a potential memory leak, as you have no handle/mechanism to remove it, except some SoftRef handling. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184766#4184766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184766

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Pluggable @EJB Resolvers

by wolfc

I'm contemplating whether to change the supply/demand chain as well. It can work with only JNDI names. In which case we would get: interface EJBDependencyResolver { | /** @return JNDI name */ | String resolveEJBReference(DeploymentUnit deploymentUnit, String beanName, Class<?> beanInterface, String mappedName); | } At leat 1 argument must be specified. mappedName is for unforeseens, because now it's the JNDI name. For WS it's a bit different, because they can invoke any public method on a bean. So they can't invoke through the current proxies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184755#4184755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184755

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by wolfc

There should be no side effects. :-) Another side effect is that the bean isn't really passivated. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184753#4184753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184753

16 years, 2 months

1
0
0 / 0

[Design of JBoss Identity] - Re: JBoss Identity Design Preview

by jeff.yuchang

"bdaw" wrote : This is something I was thinking about from the beginning. It can be done by keeping reference to the session in identity model classes. The main problem I see is the mix of two approaches: | | - most management methods in the model objects (Identity/Group/Role) | - all management methods in manager objects connected to the session (the only reason to have 4 separate managers is to not end up with 100 methods in IdentitySession) | | Now to mix - some methods in Identity/Group/Role and some in managers | | Most of the search/find/resolve methods need to remain in managers anyway. Now if you think about the assignments you can place methods you mentioned in the Identity/Group but those operating on the collections will need to remain in the managers: | | public void associateGroups(Collection<Group> parents, Collection<Group> members) throws IdentityException | | Also you can have | | group.findAssociatedGroups(GroupType groupType, boolean parent, boolean inherited, ... ) | | but then you still need to keep few of findXXX methods in the manager as they don't belong to one model object... What I'm afraid of is the confusion of users where to look for certain methods. That's why I decided to put all all methods in the managers. | | Exactly the issue that I am worrying about with my suggestion, thats what I mean complexity on the implementation, and say 'I just bring about this issue'. ;-(. We may keep it as it is now, cause I haven't come up a easy way to accomplish this change. Not sure others will have a better way? -Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184751#4184751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184751

16 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008