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

[Design of JBoss Portal] - Sharing session attribute between servelt and portlet

by sbiwal

Hi I am working with JBoss Portal 2.6.2, deployed with JBoss AS 4.2. I have the following situation - A thirdparty class calls a servlet (myServlet). Now this servlet should update a portlet (myPortlet) based on the parameters sent by the thirdparty class. In the doGet fucntion of myServlet I set the parameter received as a session attribute by - request.getSession().setAttribute(param, value); However when I get to the doView function of the portlet, this session attribute is lost. If I try a vice-versa scenario (setting attribute in Portlet and then reading from servlet) it doesn't work either !!! Please help !! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144151#4144151 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144151

16 years, 5 months

1
0
0 / 0

[Design of Persistence on JBoss] - Will JBoss 5 be fully standards compliant?

by adrianwilford

Hi I have recently had issues with JBoss 4.2.2GA not being fully JPA compliant, specifically: -JBoss not implementing the EJB 3.0 spec correctly so that it makes it very difficult to use another JPA provider like Toplink instead of Hibernate (I know that in the JBoss docs, it says that Hibernate is the only JPA provider that is supported, but this is counter to the idea of standards compliance allowing flexibility) Toplink is after all the reference implementation, and If the reference implementation is not supported, then it means that there is something seriously wrong! So.. will JBoss 5 be fully standards compliant allowing for maximum flexibility? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144148#4144148 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144148

16 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Cluster Singleton listeners

by Welle

Hmm.... Am I the only one with this problem? Does anyone use the ESB in a clustered environment? I really thought that we would get a discussion going about this, /Anders W. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144141#4144141 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144141

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Shared Transport in JGroups

by bela＠jboss.com

"bstansberry(a)jboss.com" wrote : OK, good. That knocks off the trivial stuff. I'd still like to get Bela's input on the thread_pool.queue_enabled and thread_pool.queue_max_size, where I think the values you guys had are better. | | That leaves enable_bundling, where I want to understand your usage so I can pick the best default. | | How data intensive and latency sensitive is the jbm-control channel? And is it used for request/response type messages (i.e. thread on node A sends a message, blocks waiting for a response from the other nodes)? Or just for async (thread on A sends and returns; doesn't block for response)? | | The enable_bundling value impacts that. When it is true, there can be an up to 30 ms delay before a message is sent. Adds latency to when the message arrives, which may or may not matter to JBM. That delay doesn't cause the thread that told JGroups to send the message to block -- unless the thread is blocking waiting for a response. If it's waiting for a response, that thread might wait 30 ms for the msg to be sent, plus another 30 ms for the response to be sent. | | The offset to that increased latency is higher throughput under heavy load w/ enable_bundling=true. The "udp" stack will be used for session replication, which *might* involve heavy load, so we've optimized for that. IMHO that was a marginal decision though, so I want to understand JBM's usage. Regarding bundling: if you send many (larger) messages and fill up the buffer (>= max_bundle_size), then there won't be any latency. Say, we're filling up 60'000 bytes in 2ms, then the message will get sent in 2ms. However (unless you send large return values), the responses will usually run into the max_bundle_time timeout (default: 30ms). You can tweak the max_bundle_size or max_bundle_timeout to a lower value, and/or change the enable_unicast_bundling flag. Regarding the max thread pool size: it doesn't hurt to make this value big, but make sure you also set keep_alive_time to a reasonable value, so that threads are placed back into the pool after that time elapsed, so they are available to other service. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144140#4144140 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144140

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Shared Transport in JGroups

by bela＠jboss.com

"bstansberry(a)jboss.com" wrote : | | enable_bundling: | | "udp" = true | "jbm-control" = false | | Need Bela's input here. I imagine JBM is concerned about latency, which is why they chose "false". I need to perf test http session replication with bundling on and off and see the difference. If it's not huge and JBM really needs 'false', I'm personally comfortable with 'false' as a default. | | Enabling bundling is a huge speedup. This is similar to nagling in TCP. However, if you invoke RPCs, then you should disable it. see http://wiki.jboss.org/wiki/ProblemAndClusterRPCs for details. Note that you can enable multicasts, but disable unicasts, so RPCs are bundled but individual responses are sent right away. The option is enable_unicast_bundling. [qoute] thread_pool.queue_enabled and thread_pool.queue_max_size: "udp" = false and 100 "jbm-control" = true and 1000 Need Bela's input here. The "udp" stack values came long ago from a JGroups stacks.xml. I'd imagine the JBM values would be more performant. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144138#4144138 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144138

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1278, fixing jbossas5/mc integration code

by scott.stark＠jboss.org

For example: | 11:32:52,683 WARN [MainDeployer] Failed to deploy: file:/Users/svn/JBossHead/jboss-head/testsuite/output/lib/refs.ear | org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): | | *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State} | | jboss.j2ee:ear=refs.ear,jar=refs-ejb2.jar,name=StatelessBean2,service=EJB3 | -> <UNKNOWN jboss.j2ee:ear=refs.ear,jar=refs-ejb2.jar,name=StatelessBean2,service=EJB3>{Described:** UNRESOLVED Demands 'jboss.j2ee:ear=refs.ear,jar=StatelessBean,name=refs-ejb.jar,service=EJB3' **} | | | *** CONTEXTS IN ERROR: Name -> Error | | <UNKNOWN jboss.j2ee:ear=refs.ear,jar=refs-ejb2.jar,name=StatelessBean2,service=EJB3> -> ** UNRESOLVED Demands 'jboss.j2ee:ear=refs.ear,jar=StatelessBean,name=refs-ejb.jar,service=EJB3' ** | | | at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:806) | at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:752) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144125#4144125 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144125

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1278, fixing jbossas5/mc integration code

by scott.stark＠jboss.org

The DeploymentUnit now has attachment support: | public interface DeploymentUnit | { | Object addAttachment(String name, Object attachment); | throws IllegalArgumentException for a null name | Object getAttachment(String name); | Object removeAttachment(String name); | ... | | and the KernelAbstraction install now has a DeploymentUnit parameter: | public interface KernelAbstraction extends ClientKernelAbstraction | { | public void install(String name, DependencyPolicy dependencies, DeploymentUnit unit, Object service); | and unsatisfied deployments show an error when the new JBossASKernel implementation of KernelAbstraction is used. We need a new release of ejb3 core to allow the server code to be in synch. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144124#4144124 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144124

16 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Sample JRPP client and server code?

by trustin

That's great. Thanks for the review! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144121#4144121 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144121

16 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portlet Container 1.2 changes

by julien＠jboss.com

I removed the usage of the classes org.jboss.portal.common.value.* in the portlet container and instead use a List for a preference value. This will affect the implementation of the property store implementation build on top of hibernate. I plan to remove the entire package from common once 2.7 does not use it anymore as it should not be use elsewhere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144104#4144104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144104

16 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Shared Transport in JGroups

by clebert.suconic＠jboss.com

anonymous wrote : I'd still like to get Bela's input on the thread_pool.queue_enabled and thread_pool.queue_max_size, where I think the values you guys had are better. During our latest testsuite runnings to upgrade JGroups 2.6, I've done so many runs, and at some point I was getting some failures, and I then increased those pools. At the same time I fixed increased those pools I also changed some other stuff... so I believe those numbers are better but I didn't find a scientific proof for those pools. You or Bela might suggest better numbers if you like. Regarding the JGroups behavior at our code (Or behaviour as Tim Fox would prefer :-p). I will look at the code and give you some examples tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144080#4144080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144080

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008