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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Servlet transport problem

by trustin

The tunneling client now works fine without JBAS-6814 fixed - CPU stays calm. One remaining question though is: why are two HTTP connections created when I run the 'servlet-transport' example? The first connection is created by ConnectionFactory.createConnection() in step 4, and the second connection is created by Connection.createSession() in step 5. Is this expected? It seems like the two connections are closed correctly in the end though. AND I also have found a different issue perhaps related with JBossWeb. It throws NPE on undeploy: 10:10:08,230 WARNING [HttpTunnelingChannelHandler] Unexpected exception | java.lang.NullPointerException | at org.apache.catalina.session.StandardSession.expire(StandardSession.java:730) | at org.apache.catalina.session.StandardSession.expire(StandardSession.java:660) | at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1115) | at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:150) | at org.jboss.netty.channel.socket.http.HttpTunnelingChannelHandler.channelClosed(HttpTunnelingChannelHandler.java:144) | at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:105) | at org.jboss.netty.channel.Channels.fireChannelClosed(Channels.java:564) | at org.jboss.netty.channel.local.DefaultLocalChannel.closeNow(DefaultLocalChannel.java:102) | at org.jboss.netty.channel.local.LocalClientChannelSink.eventSunk(LocalClientChannelSink.java:66) | at org.jboss.netty.channel.Channels.close(Channels.java:1043) | at org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:185) | at org.jboss.netty.channel.socket.http.HttpTunnelingServlet.streamResponse(HttpTunnelingServlet.java:99) | at org.jboss.netty.channel.socket.http.HttpTunnelingServlet.doRequest(HttpTunnelingServlet.java:62) | at org.jboss.netty.channel.socket.http.HttpTunnelingServlet.doPost(HttpTunnelingServlet.java:195) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) | at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) | at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) | at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) | at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) | at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601) | at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) | at java.lang.Thread.run(Thread.java:619) Of course, it does not affect JBM because the connections were closed already. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227370#4227370 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227370

15 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Our Adapter and Client_Acknowledge

by clebert.suconic＠jboss.com

Our Adapter is not support ClientAcknowledge. public void setAcknowledgeMode(String value) | { | if (trace) | log.trace("setAcknowledgeMode(" + value + ")"); | | if ("DUPS_OK_ACKNOWLEDGE".equals(value) || "Dups-ok-acknowledge".equals(value)) | this.acknowledgeMode = Session.DUPS_OK_ACKNOWLEDGE; | else if ("AUTO_ACKNOWLEDGE".equals(value) || "Auto-acknowledge".equals(value)) | this.acknowledgeMode = Session.AUTO_ACKNOWLEDGE; | else if ("SESSION_TRANSACTED".equals(value)) | this.acknowledgeMode = Session.SESSION_TRANSACTED; | else | throw new IllegalArgumentException("Unsupported acknowledgement mode " + value); | } | Is that on purpose? (easier to ask you guys than read the spec ;-) ) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227365#4227365 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227365

15 years

1
0
0 / 0

[Design of JBoss jBPM] - Enterprise Structure for JBPM4

by bradsdavis

With JBPM 3, we have switched between EARs and SARs. This has caused a bit of confusion and also has made things a bit complicated in terms of loader-repositories. One large jBPM client does use a dedicated loader-repository with their application, and supporting dedicated loader-repositories would be a nice thing for 4. I am not sure how this model changes for JBoss 5 though. I know with the current jBPM 3, there are a few steps to getting the loader repository to work, including moving the jbpm-enterprise.jar, and having to add the loader-repository in several configurations. The nice thing about the EAR deployment was that it only required one configuration change to have jBPM participate in a given loader-repository in JBoss. Before we move to 4, we should put as much thought into packaging as we do into the architecture to ensure that it will work with a number of different client setups. This would include: 1) Loader Repositories 2) EJB Integration I know there was talks on the forum of having a ThreadLocal type solution to calling jBPM within EJB, such that opening the context wouldnt occur multiple times for nested EJB calls. Has this been investigated for 4? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227349#4227349 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227349

15 years

1
0
0 / 0

[Design of POJO Server] - Re: Caching of classes in BaseClassLoaderDomain

by bstansberry＠jboss.com

The classloader leak tests pass. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227347#4227347 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227347

15 years

1
0
0 / 0

[Design of POJO Server] - Re: Caching of classes in BaseClassLoaderDomain

by bstansberry＠jboss.com

Just to experiment I wrapped the call to BaseClassLoader.checkCacheAndBlackList in a try/catch and caught the CNFE. The AS starts clean and the smoke tests pass. A mvn install in the jboss-cl codebase shows 3 tests with errors, but those were there before I made the change as well. Looking at the actual usage, the catch could also be inside checkCacheAndBlackList itself, but that's a protected method that declares the exception in its signature. I'm not committing this as you may have other thoughts and if not it's trivial. Now running classloader leak tests... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227339#4227339 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227339

15 years

1
0
0 / 0

[Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers

by akluge

Hi, Sorry for taking a bit of time to get back on this, but I have been busy. I would expect any given server to respond to both the Memcache and the Jboss Cache protocol. However, I would expect any given client to use only one of them. I was not planning on a handshake, but to simply have the client connect, and send requests according to its chosen protocol. Even in this case you will want to have the magic bytes. - They allow the server and the client to do a consistency check. If they see something else at the beginning of a message, they know quickly that something is wrong. - They make it easier to handle additional message types (I expect to add event notifications over the JBC protocol). - The Memcache binary protocol (http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol) already uses them, so at least for Memcache requests/responses they are required. - The Memcache protocol spec also makes the point that it makes it easier for protocol analyzers to work with the magic bytes. Thanks, Alex View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227330#4227330 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227330

15 years

1
0
0 / 0

[Design of POJO Server] - Re: Caching of classes in BaseClassLoaderDomain

by bstansberry＠jboss.com

The webapps that fail are declaring a loader-repository in jboss-web.xml. The CNFE is coming from: | Thread [main] (Suspended) | ClassLoaderDomain(BaseClassLoaderDomain).checkClassBlackList(BaseClassLoader, String, String, boolean) line: 1477 | ClassLoaderDomain(BaseClassLoaderDomain).checkClassCacheAndBlackList(BaseClassLoader, String, String, boolean) line: 1503 | BaseClassLoader.checkCacheAndBlackList(String, boolean) line: 365 | BaseClassLoader.loadClass(String, boolean) line: 429 | WebCtxLoader$ENCLoader(ClassLoader).loadClass(String, boolean) line: 299 | WebCtxLoader$ENCLoader(ClassLoader).loadClass(String) line: 251 | TomcatInjectionContainer.newInstance(String, ClassLoader) line: 262 The requested classes are in the domain's black list. I'm assuming this CNFE should be caught and the call allowed to continue on to check the parent domain. I'll look at the JBCL-100 patch to see where the likely place to catch it is. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227326#4227326 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227326

15 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Hudson almost green

by clebert.suconic＠jboss.com

I already ran it for 100 times... the test sends a lot of messages.. .so it takes some time to get that many rusn.. and I never got a failure. Perhaps it would be easy at the revision the failure happened? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227321#4227321 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227321

15 years

1
0
0 / 0

[QA of JBoss Portal] - Re: Problem with Tomcat SSO valve while being in 'Admin' rol

by sohil.shah＠jboss.com

Actually before modifying the portal's server configuration, which should work, try if modifying the jmx-console-roles.properties file and see if that works. If it does, that would be a cleaner approach. To do that, open your jmx-console-roles.properties file and add "Authenticated" to the list of roles to be associated with the admin user. So now, the file should look like this: | # A sample roles.properties file for use with the UsersRolesLoginModule | admin=JBossAdmin,HttpInvoker,Authenticated | Thanks Sohil View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227318#4227318 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227318

15 years

1
0
0 / 0

[QA of JBoss Portal] - Re: Problem with Tomcat SSO valve while being in 'Admin' rol

by sohil.shah＠jboss.com

Marek- try this. Inside jboss-portal.sar/portal-server.war/WEB-INF/web.xml, replace all occurrences of "Authenticated" configuration with "Admin" Portal expects the "Authenticated" role to be populated inside the security context, but since the jmx-console is doing the authentication, its populating the security context with what it knows which is "Admin". Let me know if this works. Thanks Sohil View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227313#4227313 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227313

15 years

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 2009