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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Replicate Deliveries on ServerConsumerImpl

by timfox

I can't run your test now since I am in the middle of a refactoring. I notice you've set blocking to true for everything though. Perhaps I'll have time to look later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195819#4195819 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195819

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Invalis Issue: SECURITY-340

by ALRubinger

I've opened https://jira.jboss.org/jira/browse/SECURITY-340, rejected by Anil as invalid. What steps do I need to take to avoid: Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission org.jboss.security.plugins. | JBossSecurityContext.setSecurityManagement) | at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) | at java.security.AccessController.checkPermission(AccessController.java:427) | at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) | at org.jboss.security.plugins.JBossSecurityContext.setSecurityManagement(JBossSecurityContext.java:123) | at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:119) ? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195794#4195794 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195794

17 years, 3 months

1
0
0 / 0

[Design of JBoss Profiler] - Cannot save data in version 1.0 CR4

by jimjxr

Hi, I'm using 1.0 CR4 to analyze a large chunck of log (more than 100MB), the analysis is successful after I boosted the memory to 1GB, but when I click save data, I got this error: description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:222) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:146) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:152) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) root cause java.lang.StackOverflowError Tomcat window has no error, no other error is found in tomcat log, any ideas? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195789#4195789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195789

17 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

by david.lloyd＠jboss.com

After spending far too long on this problem, the solution I have come up with (this time) is to have an alternate executor implementation which is used when the configuration given is known not to work with TPE. In this case, it is chosen whenever there is a blocking policy in place, but it could be made more (or less) specific if desired. The alternate implementation is designed to be correct and simple ("SimpleQueueExecutor"); thus it uses a Queue (rather than a BlockingQueue) to hold tasks and simply uses a Lock and Conditions to synchronize and block as needed, in order to allow for atomic "create-thread-or-queue" and "dequeue-or-destroy-thread" operations. It is designed to hold the lock for as small a time as possible (generally just long enough to do a couple field accesses, comparisons, and maybe a queue insert/remove) without making the code too complex. As such it is considerably simpler than ThreadPoolExecutor (less than 600 lines versus approx. 1800), though I won't place any bets as to comparative performance until I can figure out a way to get a somewhat reliable benchmark result. I'll consider it a runaway success if I achieve "approximately similar". In support of this class, there's also a simple bounded, array-backed queue class ("ArrayQueue") since there is (amazingly) no such thing in t! he JDK. As for the common-core stuff - I think that (for the most part) the various extensions can work with this pojo-centric design, but maybe not exactly as-is (since there is some tight coupling with ThreadPoolExecutor in a few places that I see from my initial read through it all). For now I think I'll just postpone the issue - at least until I have fulfilled my immediate obligations. Anyway, here's links to the more interesting points: http://anonsvn.jboss.org/repos/sandbox/david.lloyd/jboss-threads/trunk/ma... http://anonsvn.jboss.org/repos/sandbox/david.lloyd/jboss-threads/trunk/jb... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195772#4195772 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195772

17 years, 3 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Profiler Not Recording Time

by jesper.pedersen

If you got the SVN downloaded javassist.jar is in the lib/ directory - or dist/ after building the profiler. There is a small note in the documentation about the need to include javassist.jar in bin/ for EAP 4.x / JBoss AS 4.2 -- see "Core libraries". The documentation could be a lot better - the first task in that direction is the documentation environment scheduled currently for Beta4. If you could track down why the classes aren't being profiled it would be great -- maybe try inserting some System.out's in agent.ProfilerThreadImpl, agent.Agent and agent.Profiler. TIA ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195770#4195770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195770

17 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Normal SFSB Business Methods named "remove"

by ALRubinger

This one has been unaddressed for awhile now. It's the failing case associated with: https://jira.jboss.org/jira/browse/EJBTHREE-1222 Target methods are resolved based upon a hash, and the hashing function does not take the declaring class into account, thus business interfaces and EJBObject resolve their "remove" methods identically: https://jira.jboss.org/jira/browse/JBAOP-546 This cannot be fixed (to take declaring class into account). Further, we can't swap out our use of the AOP MethodHashing for our own because we only directly hash and populate the method tables for "virtual" methods; all others are done by AOP ClassAdvisor, and we don't have the hooks (presently) to redefine the hash function to be applied. So maybe our best hope is to extract out the hashing logic into a method we can override in ExtendedManagedObjectAdvisor; then ClassAdvisor calls will use our impl. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195767#4195767 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195767

17 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Replicate Deliveries on ServerConsumerImpl

by clebert.suconic＠jboss.com

I've just added JustReplicationTest. The test will pass, but you will see several exceptions on the log. This is part of another failing condition I have on MessageChunkFailover. I expect to work more on this tomorrow afternoon (your afternoon.. my morning) if you (Tim) don't fix it before. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195766#4195766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195766

17 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Replicate Deliveries on ServerConsumerImpl

by clebert.suconic＠jboss.com

I wrote a Failover test that is sending 100 messages to a live node and consuming all on the live node. (i.e. I have the backup configured, but I don't call Failover). As I ACK the messages, I'm getting several errors on not finding the MessageId on ServerConsumerImpl::deliveringRefs. After some investigation I found out that deliverReplicated is calling doHandle, and doHandle is checking for credits, even though this is documented: // We call doHandle rather than handle, since we don't want to check available credits | // This is because delivery and receive credits can be processed in different order on live | // and backup, and otherwise we could have a situation where the delivery is replicated | // but the credits haven't arrived yet, so the delivery gets rejected on backup | HandleStatus handled = doHandle(ref); | private HandleStatus doHandle(final MessageReference ref) throws Exception | { | if (availableCredits != null && availableCredits.get() <= 0) | { | return HandleStatus.BUSY; | } | | lock.lock(); | | try | { | // If there is a pendingLargeMessage we can't take another message | // This has to be checked inside the lock as the set to null is done inside the lock | if (largeMessageSender != null) | { | return HandleStatus.BUSY; | } | I'm getting several exceptions like: if (handled != HandleStatus.HANDLED) | { | throw new IllegalStateException("Reference was not handled " + ref + " " + handled); | } | and several others on not finding the MessageId. Why deliverReplicated needs to actually call handle? Shouldn't instead just adding it to the list and eventually performing preCommit? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195761#4195761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195761

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: SubProcessCancellationTest / testWithSubProcess is

by kukeltje

>From svn history it looks like Thomas did this when fixing the class to cleanup leftovers. Since there is no reference to a jira issue why it is excluded (in the wrong way anyway) I think you can safely make it undeath and see what hudson makes of it View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195759#4195759 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195759

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Use of jboss-reflect project

by bstansberry＠jboss.com

"alesj" wrote : | "anil.saldhana(a)jboss.com" wrote : | | Brian, I agree on a wiki page describing what each project does. :) | | | Not a bad idea. See: http://www.jboss.org/community/docs/DOC-13195 http://www.jboss.org/community/docs/DOC-13196 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195748#4195748 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195748

17 years, 3 months

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 December 2008