January 2010 - jboss-dev-forums - Jboss List Archives

[JBoss Profiler Development] New message: "Re: Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr"

by Tom Harris

JBoss development, A new message was posted in the thread "Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr": http://community.jboss.org/message/518641#518641 Author : Tom Harris Profile : http://community.jboss.org/people/tharris Message: -------------------------------------------------------------- I followed the instructions for using the 1.0.RC4 release, and now I get the following when starting up: this is the new DLL Running process on Windows 2180 ERROR: JVMPI, an experimental interface, is no longer supported. Please use the supported interface: the JVM Tool Interface (JVM TI). dpInspector> error in obtaining jvmpi interface pointer Error occurred during initialization of VM -Xrun library failed to init: jbossInspector Press any key to continue . . . I am running JBoss 5.1.0.GA with Java 1.6.0_17. Tom Harris -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518641#518641

15 years, 9 months

1
0
0 / 0

[JBoss Profiler Development] New message: "Re: Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr"

by Jesper Pedersen

JBoss development, A new message was posted in the thread "Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr": http://community.jboss.org/message/518634#518634 Author : Jesper Pedersen Profile : http://community.jboss.org/people/jesper.pedersen Message: -------------------------------------------------------------- No, the .SAR file enables that the profiler can be controlled through a management interface using JMX. The .WAR is only available in our repository - so you will have to build it yourself. Note, that is a lot of functionality missing - e.g. we need help from the community in this area In regards to your memory question; JBoss Profiler 2.0 is currently a pure Java profiler, which doesn't allow collecting detailed memory information. Hence only number of instances allocated for each class type is recorded. What we need is a JVMTI implementation that can collect the necessary information. But also in this case we need some help from the community. You may want to take a look at the JBoss Profiler 1.0 series - which is based on JVMTI. HTH -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518634#518634

15 years, 9 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: StructureModificationChecker and Synch with VFS3"

by John Bailey

JBoss development, A new message was posted in the thread "StructureModificationChecker and Synch with VFS3": http://community.jboss.org/message/518633#518633 Author : John Bailey Profile : http://community.jboss.org/people/johnbailey Message: -------------------------------------------------------------- Right. The problem is the VFS is setup to show the current structure. So archives that are unzipped and mounted will in essence hide the original archive. To work around this we can create another VFS mount for the original file, but then anyone who needs to determine modifications would need to be aware if changes were made to the original. So it will get ugly quick. Once really ugly example is what can occur with WAR deployments: Ex. /path/test.war 1. The original archive is mounted as a Zip archive creating a temporary location like /${jboss.temp.dir}/1-test.war 2. The temp location is mounted in the original VFS location 3. The WAR deployer invokes a deep copy of the archive to avoid file locking problems with creates another temp location /${jboss.temp.dir}/2-test.war 4. The temp location is mounted in the original VFS location The same path in VFS has represented three different OS filesystem locations. The code checking for modifications needs to know the original archive file to check. It can't get it from the VFS without some implementation details being exposed. By design the client view of the VFS only exposes the current state of the mounts, and if you want to know if something is modified, you will be checking the current structure regardless of what originally existed in various mount points. Since the modifications being checked for are occurring on the original files, a lot of code and workarounds could be avoided by NOT using the VFS to check for modifications. Any thoughts? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518633#518633

15 years, 9 months

1
0
0 / 0

[JBoss Profiler Development] New message: "Re: Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr"

by Tom Harris

JBoss development, A new message was posted in the thread "Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr": http://community.jboss.org/message/518632#518632 Author : Tom Harris Profile : http://community.jboss.org/people/tharris Message: -------------------------------------------------------------- Thanks, I should have read the end of the thread a little closer, as I see now you guys were talking about a WAR file not being included. (I thought the jboss-profiler.sar file WAS the GUI. Not sure what it could be if not a GUI.) Once I ran the command line tool, I realized it was dumping reports into the working folder. Now, I see lots of timing stats, but very little info with regards to memory. We are getting lots of OutOfMemoryErrors in production, and I was tasked with finding the root cause ASAP. My jboss-profiler.properties file in the jboss/bin folder has the setting "memory=yes", so I assumed that would mean it would collected memory allocation counts, etc. How do I collect and view that kind of memory allocation information, like in YourKit or OptimizeIt? Tom -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518632#518632

15 years, 9 months

1
0
0 / 0

[JBoss Profiler Development] New message: "Re: Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr"

by Jesper Pedersen

JBoss development, A new message was posted in the thread "Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr": http://community.jboss.org/message/518630#518630 Author : Jesper Pedersen Profile : http://community.jboss.org/people/jesper.pedersen Message: -------------------------------------------------------------- The web-frontend for the 2.0 series isn't included yet in the distribution as it is still under development. You can use the command line client to control and retrieve the results. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518630#518630

15 years, 9 months

1
0
0 / 0

[JBoss Profiler Development] New message: "Re: Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr"

by Tom Harris

JBoss development, A new message was posted in the thread "Thoughts on jboss-profiler-2.0.Beta3.SP1 install/usage instr": http://community.jboss.org/message/518628#518628 Author : Tom Harris Profile : http://community.jboss.org/people/tharris Message: -------------------------------------------------------------- I followed the instructions in the PDF for the 2.0.0.Beta5 version, including the step to stick the jboss-profiler.sar into the server deploy folder. However, when I start up the JBoss server (v5.1.0GA) and attempt to browse to "http://localhost:8080/jboss-profiler/", I get a 404 error. What gives? How do I get the UI to come up? Did I misconfigure something? I followed the instructions to the letter. Tom Harris Axispoint, Inc. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518628#518628

15 years, 9 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: StructureModificationChecker and Synch with VFS3"

by Brian Stansberry

JBoss development, A new message was posted in the thread "StructureModificationChecker and Synch with VFS3": http://community.jboss.org/message/518627#518627 Author : Brian Stansberry Profile : http://community.jboss.org/people/bstansberry@jboss.com Message: -------------------------------------------------------------- Note that the farming service also does a scan of a portion of the VFS, with the assumption that it's looking at the original files. This is encapsulated in https://svn.jboss.org/repos/jbossas/trunk/system/src/main/java/org/jboss/... See the getCurrentContentMetadata() method. This is managed by ClusteredDeploymentRepository, which is one of the ProfileService repository impls Scott was talking about. The scan is triggered by the HDScanner. This differs from the scan performed by the non-clustered repository impl in that it's interested in all files, not just those that could trigger a redeploy. And it's not interested in the internals of zipped archives. Basically it wants to detect any modified files so it can replicate them to the cluster. If this scan were delegated to VFS, it would need to get back the relative path, timestamp and directory/leaf status of all files under the root. Hmm, replicating the file means being able to read the original file. That's a problem if it is hidden. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518627#518627

15 years, 9 months

1
0
0 / 0

[JBoss Remoting Development] Document updated/added: "R3.1 Remote Protocol Specification"

by David Lloyd

JBoss development, The document "R3.1 Remote Protocol Specification", was updated Jan 6, 2010 by David Lloyd. To view the document, visit: http://community.jboss.org/docs/DOC-14535#cf Document: -------------------------------------------------------------- h1. Remote Protocol Specification h2. Table of Contents * #Remote_Protocol_Specification ** #Table_of_Contents ** #Overview ** #Message_Format *** #Framing *** #Header **** #First_and_Last_Markers **** #End_of_Data_Marker *** #Flow_Control ** #Negotiation ** #Security *** #Confidentiality *** #Authentication ** #Remoting_Clients ** #Remoting_Requests_And_Replies h2. Overview The "remote" protocol is the protocol by which two Remoting 3 endpoints may be connected to communicate with one another. The protocol requirements are: 1. Security: provide authentication and confidentiality support for clients and servers 2. Concurrency: allow multiple clients and requests to be active concurrently 3. Streaming: allow embedded streams 4. Efficiency: Make requests as compact as possible. 5. Performance: Provide equivalent or better latency characteristics than Remoting 2. h2. Message Format h3. Framing Since the "remote" protocol is a message-oriented protocol, and TCP is a stream-oriented protocol, an additional level of framing is required. The "remote" protocol uses a simple length-data framing scheme. Bit #: 7 6 5 4 3 2 1 0 Byte# +---+---+---+---+---+---+---+---+ 0 | Length (MSB) | +-------------------------------+ 1 | Length (LSB) | +-------------------------------+ 2+ | Data ... | | | : : . . Since every message has a predetermined length, the TCP_NODELAY socket option should *always* be employed to minimize message transmission latency on send. h3. Header All regular messages in the "remote" protocol have a common structure. They are all preceded by a message header, which associates the message with a specific request, client, or stream channel. Bit #: 7 6 5 4 3 2 1 0 Byte# +---+---+---+---+---+---+---+---+ 0 | L | F | A | X | S.Ch.ID (MSB) | +---+---+---+---+---+---+---+---+ 1 | Source Channel ID (LSB) | +---+---+---+---+---+---+---+---+ 2 | X | X | D | E | D.Ch.ID (MSB) | +---+---+---+---+---+---+---+---+ 3 | Destination Channel ID (LSB) | +-------------------------------+ 4 | Data... | : : . . The meaning of each field is as follows: * *X* - Reserved, set to 0 for forward compatibility. * *L* - "Last", indicates that this message will be the last in the stream; once * *F* - "First", indicates that this message is the first message in this direction for a channel pair. * *A* - "Acknowledge", indicates that a previously received message should be acknowledged (see *flow control* for more information). * *D* - "Data", a marker which indicates that the message contains a data message (with a length of zero or more). * *E* - "End-of-data", a marker which indicates the end of a substream. * *Source Channel ID* - the channel ID of the sender. * *Destination Channel ID* - the channel ID of the recipient. A subchannel is uniquely identified by a source/destination channel ID pair, not unlike how unique TCP connections are identified. This means that more than one source channel ID can be connected to a destination channel ID, and there can be more than one connection with the same source ID, so long as the destination channel ID is different between each connection. h4. First and Last Markers The First and Last markers on a message delineate the beginning and ending of a connection. Once a Last marker is read on the remote side, no further data will be received on the channel. When a Last marker is both sent and received, the associated channel ID pair becomes free for reuse. h4. End of Data Marker The End-of-data marker does not have a significance to the overall protocol; it is used by the transport to mark the end of a message. The bit will be set on the last packet of such a message. h3. Flow Control Flow control is accomplished by two mechanisms. The first is a negotiated limit on the number of allowed concurrent subchannels. When this limit is reached, the peer interested in establishing a new subchannel is forced to wait. If the peer ignores the subchannel limit, the connection may be terminated immediately. The second mechanism is a fixed window size associated with each subchannel. For a subchannel with a window size of +N+, each peer may send up to +N+ messages on that subchannel without waiting for an "acknowledge" reply. Further messages may not be sent until a message is received with the "A" bit set, at which time exactly one message is considered to be acknowledged. If the window size for a subchannel is disregarded, the connection may be terminated immediately. Such an acknowledgement may be sent in conjunction with a data message travelling in the opposite direction, or it may be sent as a standalone (dataless) message. h2. Negotiation In order to reach agreement on what features should be available on the connection (selecting a marshaller, agreeing on parameters such as class tables and so forth), a negotiation phase is employed after authentication completes but before requests may be transferred. h2. Security h3. Confidentiality Confidentiality protection is implemented via TLS. All TLS authentication options are supported, including but not limited to client authentication via TLS. These connection parameters may be specified as options when the connection is created. h3. Authentication Server authentication occurs naturally via the TLS server certificate validation process. While clients may also be authenticated via this process, SASL-based authentication is also performed by the server. If, for some reason, client authentication is not desired via SASL, then a NULL SASL mechanism should be selected. If both client and server authentication is desired via SASL, then an appropriate mechanism supporting both should be chosen. h2. Remoting Clients h2. Remoting Requests And Replies --------------------------------------------------------------

15 years, 9 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Optimizing aop lifecycle"

by Kabir Khan

JBoss development, A new message was posted in the thread "Optimizing aop lifecycle": http://community.jboss.org/message/518600#518600 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- This has been done. For the record, once we add this to AS we need to add the in/uncallbacks to BeanAnnotationAdapter in the bootstrap as shown here (Ales's suggestion worked): <bean name="BeanAnnotationAdapterFactory" class="org.jboss.kernel.plugins.annotations.BeanAnnotationAdapterFactory"> <constructor factoryMethod="getInstance"/> </bean> <bean name="BeanAnnotationAdapter"> <constructor factoryMethod="getBeanAnnotationAdapter"> <factory bean="BeanAnnotationAdapterFactory"/> </constructor> <incallback method="addAnnotationPlugin"/> <uncallback method="removeAnnotationPlugin"/> </bean> -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518600#518600

15 years, 9 months

1
0
0 / 0

[Security Development] New message: "Re: client authentication on a JRMP SSL connection; multiple"

by Stefan Guilhen

JBoss development, A new message was posted in the thread "client authentication on a JRMP SSL connection; multiple key": http://community.jboss.org/message/518593#518593 Author : Stefan Guilhen Profile : http://community.jboss.org/people/sguilhen@redhat.com Message: -------------------------------------------------------------- I've posted a reply to each one of the threads. With the exception of the second thread (client auth option in JaasSecurityDomain) I think all the features are pretty useful and we should include them. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/518593#518593

15 years, 9 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 January 2010