[JBoss AOP] - Re: How to set a breakpoint for weaved classes.
by flavia.rainone＠jboss.com
It is true that there is code running you can't see the lines it came from. AFAIK, there is no solution for this as you don't have the sources of the code that JBoss AOP weaves in your classes.
Still, when I need to debug some aspectized class, I just add the breakpoint to the parts that I have written and that I want to debug, and it works. Inclusively, it works when I need to debug an aspect, I just add the breakpoint to the aspect itself and Eclpise stops when the aspect execution starts.
If you run into a point of the stack where Eclipse gets lost (i.e., where it doesn't show where is the line it is running), just proceed pressing F5 until you get to your aspects code or until you get back to your aspectized class. I'm writing a tutorial about this at our blog, by the way. The part II, that talks about this stuff, should come out really soon.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185562#4185562
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185562
17 years, 6 months
[Remoting] - Re: java.net.SocketException: Connection reset
by ron.sigal＠jboss.com
Hi Andrej,
When the exception is thrown, Remoting has just created a new socket and is trying to create an ObjectInputStream, the constructor for which tries to read a stream header. While it's waiting on the stream header, it is informed that the server has closed the socket, as indicated by "java.net.SocketException: Connection reset".
The question is, then, what is going on at the server? One possibility, if the server is very busy, is that all of the worker threads are in use and the server tries to interrupt one to reuse it. If that's the case, then increasing the size of the worker thread pool might alleviate the problem. In fact, I see you have already increased it from the default size (300) to 400. Did that reduce the frequency of the exception?
It would be very useful to see what's going on at the server by setting the log level for Remoting to TRACE. You can do that by adding
| <category name="org.jboss.remoting">
| <priority value="TRACE"/>
| </category>
|
to server/$CONFIG/conf/jboss-log4j.xml.
By the way, I see that you've also added
| <attribute name="socket.check_connection" isParam="true">true</attribute>
|
to the EJB3 Connector configuration. If you did that to try to solve this problem, it was a good guess but not relevant to the problem I see in the stacktrace. Setting "socket.check_connection" to "true" will enable an extra round trip communication when the Remoting client tries to reuse a connection from the connection pool. But the problem in the stacktrace occurs when a new connection is being created. If that's the only reason for enabling connection checking, you might want to take it out, since it will introduce extra latency and network traffic.
Let me know what happens with the server log.
-Ron
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185561#4185561
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185561
17 years, 6 months
[JBoss AOP] - Re: The use of Hotswapping
by flavia.rainone＠jboss.com
Hello,
JBoss AOP is a dynamic weaver because it allows you to weave in and out aspects at runtime. How it does this behind the scenes depends on the mode you run it:
-no hotswap (regardless of whether you use aopc or loadtime weaving) it will add calls to empty invocations at the points you have prepared for dynamic weaving. At runtime, when you add aspects to those points, it will just add those aspects ot the invocation stack, without changing any code, as all the needed changes have already been performed.
-hotswap JBoss AOP will add only the auxiliary methods and fields to perform interception of your prepared points. This means that you code grows a little bit bigger (not too much bigger) compared with the unweaved version, but you won't have loss of performance, as your control flow is unchanged. When you add/remove aspects at runtime, JBoss AOP will recompile the affected classes, changing the control flow of the affected points, and reload them. This step is what we call hotswap.
In either case, you want to prepare specific points of your applications that you want to be target of runtime operations. Hotswap brings in great advantage because it won't cause any performance overhead to your application in the absence of aspects. That said, if you plan to have your points always intercepted (i.e., there will always be one or more aspects applied to the prepared points), there is no gain in using hotswap. You won't be able of taking advantage of the fact that your code runs faster in the absence of aspects, because there will always be at least one aspect performing interception on those points. On the other hand, if you think that at some moments of your application execution there will be one or more prepared joinpoints not being intercepted, then hotswap is the best choice.
IMO, the dynamic nature of JBoss AOP can be very handy in the scenario you described. It is not about being able of changing your application code without recompilation. Think about it, how can you garantee consistency if there is code calling a method and suddenly you remove a method?
It is about being able of changing your application at runtime. You can easily write a thread that watches a deployment directory or something. At this directory you deploy and undeploy a file containing the new security rules. This thread process the new rules and performs the changes by adding and removing aspects. Or, it may be the case of not using dynamic AOP at all. You can have a Security aspect running all the time, and this thread just reconfigures this aspect setting the new properties on it. It depends on the needs of your application.
If you want maximum flexibility, you can support deployment of aspects at this deployment directory. You can just load jars containing your security aspects and jboss-aop.xml files when such a jar file gets deployed. and remove those aspects when the jar gets undeployed. This is more or less what we do in JBoss AS, and this will allow you to write new code (the aspects), compile this code, package it and insert it into your running application, without having to recompile your entire application.
Finally, note that you are not stuck with a deployment directory. This is only one possibility. You can also allow configurations by some GUI instead of using a deploy directory, or having a thread paying attention to somethinig else in order to determine when to perform dynamic AOP operations.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185560#4185560
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185560
17 years, 6 months
[JBoss Cache: Core Edition] - Re: 2.2 to 3.0CR2
by manik.surtani＠jboss.com
"lovelyliatroim" wrote : anonymous wrote :
| | I'm guessing you just forgot to paste those in here?
| |
| Yes just gave the essential bits needed. Have so much config in there its not worth posting the whole lot ;)
|
Yeah, I was testing this with the config transformer script and it worked fine but only after I added the container elements as per my previous post.
"lovelyliatroim" wrote : I assume that fixes the issue with the cacheloader and not why it parses the 3.0.x format config file with a 2.x XML Parser?
|
Yes. I cannot recreate the parser issue, hence my comment above re: the XML you posted.
"lovelyliatroim" wrote :
| Havent checked out and built it yet but the headline is misleading for me in this case, in sample test case the node exists, the node is not null or maybe the heading of the ticket is misleading.
|
Not really - the root cause of the problem is when you do the put(), before the node exists.
"lovelyliatroim" wrote :
| No problem, any idea of when a final release will be made? Evaluating my apps test cases with 3.0.X version, have to end of the week to make final decision on to step up or not but are you running on schedule for next weeks GA release ;) ??
|
Still pretty much on schedule, of course it may slip if something nasty comes up in integration testing. There is a lot of that going on with the JBoss AS and Hibernate codebases at the moment, as well as the community at large.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185550#4185550
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185550
17 years, 6 months