Re: problem in updating confluence
Hi Kevan Thanks for the update.Still I have the same problem hope things will be back soon. Regards Kanchana On 10/24/06, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 23, 2006, at 12:31 AM, Kanchana Welagedara wrote: Hi All I'm having a problem to confluence.Presently I have no access to the confluence.can any body please update me on what's going on and when will be available ? Kanchana, The ASF moved a lot of servers this weekend. Mailing lists and many other pieces of the infrastructure have been down for a couple of days. Things seem to be returning to normal. http://cwiki.apache.org/geronimo/ is up for me. IIUC everything should be back to normal tomorrow... --kevan
Re: problem to access the confluence
I'll do. Thanks for the update Hernan Regards Kanchana On 10/23/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi Kanchana, The ASF infrastructure team is moving the servers to a new location. Service during Sunday and Monday will be affected, not sure about tomorrow. Mailing distribution lists are also affected, so feel free to shoot any direct mails if you don't see any activity on the mailing lists. Cheers! Hernan Kanchana Welagedara wrote: Hi All I'm having a problem to confluence.Presently I have no access to the confluence.can any body please update me on what's going on and when will be available ? Thanks and Regards Kanchana
Re: svn commit: r466869 - /geronimo/genesis/trunk/plugins/tools-maven-plugin/src/main/java/org/apache/geronimo/genesis/plugins/tools/CopyLegalFilesMojo.java
On 10/23/06, Jason Dillon [EMAIL PROTECTED] wrote: Why? If you want to add more files to be included then we should expose the list as configuration... which is what the FIXME comment says right above the new file includes you've added. I knew I should've done it better, but I was completely out of time to finish some OpenEJB stuff and couldn't make it. Well, I was about to have made it, but it quickly turned out to have taken me more time I could spare. Sorry. What exactly is DISCLAIMER* used for? I don't know. I spot it on a mailing list when I put it in and while including other files put it, too. I can't find it anywhere, but I'm sure I've read somewhere about it. I remember I was surprised to see yet another file to include in jars. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r466869 - /geronimo/genesis/trunk/plugins/tools-maven-plugin/src/main/java/org/apache/geronimo/genesis/plugins/tools/CopyLegalFilesMojo.java
No worries :-) --jason On Oct 23, 2006, at 1:12 PM, Jacek Laskowski wrote: On 10/23/06, Jason Dillon [EMAIL PROTECTED] wrote: Why? If you want to add more files to be included then we should expose the list as configuration... which is what the FIXME comment says right above the new file includes you've added. I knew I should've done it better, but I was completely out of time to finish some OpenEJB stuff and couldn't make it. Well, I was about to have made it, but it quickly turned out to have taken me more time I could spare. Sorry. What exactly is DISCLAIMER* used for? I don't know. I spot it on a mailing list when I put it in and while including other files put it, too. I can't find it anywhere, but I'm sure I've read somewhere about it. I remember I was surprised to see yet another file to include in jars. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Commented: (AMQ-991) ActiveMQ 4.0.1 crashes when using client from trunk.
[
https://issues.apache.org/activemq/browse/AMQ-991?page=comments#action_37263 ]
james strachan commented on AMQ-991:
There was a gremlin in trunk for a little while that made NMS not work with
older ActiveMQ brokers. Though AFAIK this should be resolved now.
ActiveMQ 4.0.1 crashes when using client from trunk.
Key: AMQ-991
URL: https://issues.apache.org/activemq/browse/AMQ-991
Project: ActiveMQ
Issue Type: Bug
Components: NMS (C# client)
Reporter: Pawel Niewiadomski
I tried today to use C# client from trunk agains ActiveMQ 4.0.1 server. This
caused server to die totally. Following error message was shown by server:
{noformat}
Exception in thread ActiveMQ Transport: tcp:///127.0.0.1:1699
java.lang.Illega
lArgumentException: Invalid version: 2, could not load
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329)
at
org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569)
at
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException:
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104)
at
org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327)
... 6 more
{noformat}
I then used ActiveMQ 4.0.2 server and it worked. Isn't that client should
automatically negotiate protocol with server? Why server after this error
dies totally? (new client connecting were not handled at all, everything
died).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-988) Thread synchronization error in TcpTransport
[ https://issues.apache.org/activemq/browse/AMQ-988?page=all ] Rob Lugt updated AMQ-988: - Attachment: amq988-patch.txt Please apply the attached patch, which fixes a bug in OpenWireBinaryReader.ReadString. This bug involves an incorrect call of the Read(byte[] buffer, int index, int count) method. Teh function requires that exactly the specified number of bytes are read from the input stream, but the way it is currently written it will read any amount up to the specified number of bytes (depending on what data is available in the socket input buffer). The result of this bug is a corrupt message when the required data is not in the socket input buffer (which, for me, happens as soon as the message rate exceeds 100 msgs per second). The read-loop thread terminates and no further messages are received. This is the true underlying cause of this bug. The earlier analysis on threading appears tro be superfluous (but it's probably worth keeping the dual NetworkStreams as this class is not advertised as threrad-safe). Regards Rob Lugt Thread synchronization error in TcpTransport Key: AMQ-988 URL: https://issues.apache.org/activemq/browse/AMQ-988 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: Rob Lugt Fix For: 4.1 Attachments: amq988-patch.txt I have a problem where my C# client application crashes when placed under load. It's taken a while to get to the bottom of it, but I believe I have identified the problem and luckily there's a simple solution. The AMQ .Net client uses a common pattern where a full-duplex TCP/IP connection is established with the broker, and the client uses two threads to concurrently read and write data to/from the underlying socket - one thread reading from a Reader object and the other writing to a Writer object. The TcpTransport.Start() method contains the following:- NetworkStream networkStream = new NetworkStream(socket); socketWriter = new OpenWireBinaryWriter(networkStream); socketReader = new OpenWireBinaryReader(networkStream); This pattern is explicitly allowed in Java and Win32 applications, but .Net is a little vague on the subject. The Microsoft documentation [1] suggests use of the asynchronous read/write calls for multithreaded applications, but that would significantly complicate the C# client which relies on blocking stream behaviour. On the same doc page Microsoft does specifiy that the Socket class is thread-safe, which I take to mean that concurrent read/write calls are permitted, however the same is not true of NetworkStream [2]. Perhaps it would be reasonable to expect NetworkStream to have no internal state other than the Socket it contains, but apparently this is not the case because I've identified that it is a corrupt NetworkStream which is causing my application to crash under load. After some experimentation and a fair amount of load testing, I think the solution is a simple change to the TcpTransport.start() method to use a separate NetworkStream for input and output operations. e.g. :- NetworkStream inputNetworkStream = new NetworkStream(socket); NetworkStream outputNetworkStream = new NetworkStream(socket); socketWriter = new OpenWireBinaryWriter(inputNetworkStream); socketReader = new OpenWireBinaryReader(outputNetworkStream); This works for me and my test client has now been running for 16 hours without crashing (before it would rarely last longer than 10 minutes). Regards Rob Lugt [1] http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.aspx [2] http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] Rob Lugt reassigned AMQ-995: Assignee: james strachan Hi James. Please review and apply supplied patch. An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Attachments: amq995-patch.txt If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-988) Thread synchronization error in TcpTransport
[ https://issues.apache.org/activemq/browse/AMQ-988?page=all ] Rob Lugt reassigned AMQ-988: Assignee: james strachan (was: Rob Lugt) Hi James. Please review and apply supplied patch. Thread synchronization error in TcpTransport Key: AMQ-988 URL: https://issues.apache.org/activemq/browse/AMQ-988 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Fix For: 4.1 Attachments: amq988-patch.txt I have a problem where my C# client application crashes when placed under load. It's taken a while to get to the bottom of it, but I believe I have identified the problem and luckily there's a simple solution. The AMQ .Net client uses a common pattern where a full-duplex TCP/IP connection is established with the broker, and the client uses two threads to concurrently read and write data to/from the underlying socket - one thread reading from a Reader object and the other writing to a Writer object. The TcpTransport.Start() method contains the following:- NetworkStream networkStream = new NetworkStream(socket); socketWriter = new OpenWireBinaryWriter(networkStream); socketReader = new OpenWireBinaryReader(networkStream); This pattern is explicitly allowed in Java and Win32 applications, but .Net is a little vague on the subject. The Microsoft documentation [1] suggests use of the asynchronous read/write calls for multithreaded applications, but that would significantly complicate the C# client which relies on blocking stream behaviour. On the same doc page Microsoft does specifiy that the Socket class is thread-safe, which I take to mean that concurrent read/write calls are permitted, however the same is not true of NetworkStream [2]. Perhaps it would be reasonable to expect NetworkStream to have no internal state other than the Socket it contains, but apparently this is not the case because I've identified that it is a corrupt NetworkStream which is causing my application to crash under load. After some experimentation and a fair amount of load testing, I think the solution is a simple change to the TcpTransport.start() method to use a separate NetworkStream for input and output operations. e.g. :- NetworkStream inputNetworkStream = new NetworkStream(socket); NetworkStream outputNetworkStream = new NetworkStream(socket); socketWriter = new OpenWireBinaryWriter(inputNetworkStream); socketReader = new OpenWireBinaryReader(outputNetworkStream); This works for me and my test client has now been running for 16 hours without crashing (before it would rarely last longer than 10 minutes). Regards Rob Lugt [1] http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket.aspx [2] http://msdn2.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] Rob Lugt updated AMQ-995: - Attachment: amq995-patch.txt Attached patch does 3 things: 1) Adds explitic Close() method and allows Close/Dispose to be called multipel times 2) Differentiates between exceptions that occur during read/parse and those that occur in the message handler 3) Closes socket if IO exception occurs to prevent further use of the (now invalid) socket. An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Attachments: amq995-patch.txt If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
Message dispatcher issues (use dedicated dispatching thread for each session) - Key: AMQ-999 URL: https://issues.apache.org/activemq/browse/AMQ-999 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: Rob Lugt There are a number of issues with the dispatching of inbound messages. - A slow consumer will potentially use and block all ThreadPool threads - Use of a ThreadPool thread to dispatch a single message is inefficient due to context switching - No mechanism to suspend asynchronous delivery to a session (i.e. Connection.Stop() is currently a no-op) - Retroactive consumer is currently broken because retoractive messages are delivered before the listener delegate is assigned. - [minor] Application cannot predict which thread messages will be dispatched on All of these problems can simply be resolved by creating a dedicated dispatcher thread for a session -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] Rob Lugt updated AMQ-995: - Attachment: (was: amq995-patch.txt) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-991) ActiveMQ 4.0.1 crashes when using client from trunk.
[
https://issues.apache.org/activemq/browse/AMQ-991?page=comments#action_37268 ]
Pawel Niewiadomski commented on AMQ-991:
I updated libraries today using trunk and still server crashes.
ActiveMQ 4.0.1 crashes when using client from trunk.
Key: AMQ-991
URL: https://issues.apache.org/activemq/browse/AMQ-991
Project: ActiveMQ
Issue Type: Bug
Components: NMS (C# client)
Reporter: Pawel Niewiadomski
I tried today to use C# client from trunk agains ActiveMQ 4.0.1 server. This
caused server to die totally. Following error message was shown by server:
{noformat}
Exception in thread ActiveMQ Transport: tcp:///127.0.0.1:1699
java.lang.Illega
lArgumentException: Invalid version: 2, could not load
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329)
at
org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569)
at
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException:
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104)
at
org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327)
... 6 more
{noformat}
I then used ActiveMQ 4.0.2 server and it worked. Isn't that client should
automatically negotiate protocol with server? Why server after this error
dies totally? (new client connecting were not handled at all, everything
died).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] Rob Lugt updated AMQ-995: - Attachment: amq995-patch.txt Note: This patch requires revised version of AtomicBoolean (attached) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Attachments: amq995-patch.txt If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] Rob Lugt updated AMQ-995: - Attachment: AtomicBoolean.cs Added Value property An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Attachments: amq995-patch.txt, AtomicBoolean.cs If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
[ https://issues.apache.org/activemq/browse/AMQ-999?page=all ] Rob Lugt updated AMQ-999: - Attachment: AtomicBoolean.cs Added Value property (this file also supplied in AMQ-995) Message dispatcher issues (use dedicated dispatching thread for each session) - Key: AMQ-999 URL: https://issues.apache.org/activemq/browse/AMQ-999 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: Rob Lugt Attachments: AtomicBoolean.cs There are a number of issues with the dispatching of inbound messages. - A slow consumer will potentially use and block all ThreadPool threads - Use of a ThreadPool thread to dispatch a single message is inefficient due to context switching - No mechanism to suspend asynchronous delivery to a session (i.e. Connection.Stop() is currently a no-op) - Retroactive consumer is currently broken because retoractive messages are delivered before the listener delegate is assigned. - [minor] Application cannot predict which thread messages will be dispatched on All of these problems can simply be resolved by creating a dedicated dispatcher thread for a session -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
[ https://issues.apache.org/activemq/browse/AMQ-999?page=all ] Rob Lugt updated AMQ-999: - Attachment: DispatchingThread.cs New class: DispatchingThread. This is a worker thread attached to a session, which has responsibility for asynchronous dispatching of inbound messages to all consumers for the session. Message dispatcher issues (use dedicated dispatching thread for each session) - Key: AMQ-999 URL: https://issues.apache.org/activemq/browse/AMQ-999 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: Rob Lugt Attachments: AtomicBoolean.cs, DispatchingThread.cs There are a number of issues with the dispatching of inbound messages. - A slow consumer will potentially use and block all ThreadPool threads - Use of a ThreadPool thread to dispatch a single message is inefficient due to context switching - No mechanism to suspend asynchronous delivery to a session (i.e. Connection.Stop() is currently a no-op) - Retroactive consumer is currently broken because retoractive messages are delivered before the listener delegate is assigned. - [minor] Application cannot predict which thread messages will be dispatched on All of these problems can simply be resolved by creating a dedicated dispatcher thread for a session -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
[ https://issues.apache.org/activemq/browse/AMQ-999?page=all ] Rob Lugt updated AMQ-999: - Attachment: amq999-patch.txt Patch to use dedicated DispacherThread instead of the application ThreadPool. In addition to using the dedicated thread, this patch also moves the NMS client closer to the JMS specification: Connection.Start() and Connection.Stop() now perform as advertised for asynchronous message delievery (but they have no affect on synchronous delivery). The big difference between JMS and NMS at the moment is that a new session is started by default (whereas a JMS connection is stopped I believe). I've done this to ensure backwards compatability with existing .Net users, but am more than happy for it to be reversed to align with JMS. Retroactive consumers are catered for by setting the message delivery event at the same tiem as registering an asynchronous even listener - so that messages already received will be delivered immediately. Where applicable I've also added Close methods to compliment Dispose() and to make both Close and Dispose behave correctly when called multiple times. Use of a dedicated dispatching thread improves message throughput in my test client by about 40%! Message dispatcher issues (use dedicated dispatching thread for each session) - Key: AMQ-999 URL: https://issues.apache.org/activemq/browse/AMQ-999 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: Rob Lugt Attachments: amq999-patch.txt, AtomicBoolean.cs, DispatchingThread.cs There are a number of issues with the dispatching of inbound messages. - A slow consumer will potentially use and block all ThreadPool threads - Use of a ThreadPool thread to dispatch a single message is inefficient due to context switching - No mechanism to suspend asynchronous delivery to a session (i.e. Connection.Stop() is currently a no-op) - Retroactive consumer is currently broken because retoractive messages are delivered before the listener delegate is assigned. - [minor] Application cannot predict which thread messages will be dispatched on All of these problems can simply be resolved by creating a dedicated dispatcher thread for a session -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
[ https://issues.apache.org/activemq/browse/AMQ-999?page=all ] Rob Lugt reassigned AMQ-999: Assignee: james strachan (was: Rob Lugt) Hi James. Please review and apply the attached patches. Message dispatcher issues (use dedicated dispatching thread for each session) - Key: AMQ-999 URL: https://issues.apache.org/activemq/browse/AMQ-999 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Attachments: amq999-patch.txt, AtomicBoolean.cs, DispatchingThread.cs There are a number of issues with the dispatching of inbound messages. - A slow consumer will potentially use and block all ThreadPool threads - Use of a ThreadPool thread to dispatch a single message is inefficient due to context switching - No mechanism to suspend asynchronous delivery to a session (i.e. Connection.Stop() is currently a no-op) - Retroactive consumer is currently broken because retoractive messages are delivered before the listener delegate is assigned. - [minor] Application cannot predict which thread messages will be dispatched on All of these problems can simply be resolved by creating a dedicated dispatcher thread for a session -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-996) IConnection requires Start(), Stop() and Close() methods
[ https://issues.apache.org/activemq/browse/AMQ-996?page=all ] Rob Lugt reassigned AMQ-996: Assignee: james strachan Hi James. This is resolved by the patch supplied for AMQ-999. Please review and resolve if you are satisfied. IConnection requires Start(), Stop() and Close() methods Key: AMQ-996 URL: https://issues.apache.org/activemq/browse/AMQ-996 Project: ActiveMQ Issue Type: Improvement Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan These three methods are needed to bring IConnection closer to the JMS Connection interface, and also provide important capabilities. Start() and Stop() methods should start and stop/join the underlying transport's reader thread. Close() should perform the tasks described in the JMS specification (ie wait for current message to be processed), whereas Dispose should probably concern itself simply with freeing up resources. Both Close() and Dispose() should be able to be called multiple times without throwing an exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-990) Leaving threads running if Connection.Dispose fails.
[ https://issues.apache.org/activemq/browse/AMQ-990?page=all ] Rob Lugt reassigned AMQ-990: Assignee: james strachan Hi James. This is resolved by the patch supplied for AMQ-999. Please review and resolve this issue if you are satisfied. Regards Rob Lugt Leaving threads running if Connection.Dispose fails. Key: AMQ-990 URL: https://issues.apache.org/activemq/browse/AMQ-990 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Reporter: Pawel Niewiadomski Assigned To: james strachan I faced today following error - in Connection.Dispose call to DisposeOf(ConnectionId); fails with exception. This causes Connection.Dispose to be aborted leading to thread responsible for communication not to be joined. I'm talking about the thread created in TcpTransport. closing = true; DisposeOf(ConnectionId); // this causes exception and aborts further execution on this scope sessions.Clear(); transport.Oneway(new ShutdownInfo()); transport.Dispose(); // this is responsible for joining the thread and closing sockets closed = true; In summary - thread is still running and we can't get rid of it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] Rob Lugt updated AMQ-995: - Attachment: (was: amq995-patch.txt) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Attachments: AtomicBoolean.cs If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-995) An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app)
[ https://issues.apache.org/activemq/browse/AMQ-995?page=all ] Rob Lugt updated AMQ-995: - Attachment: amq995-patch.txt An unhandled exception in the TcpTransports' reader thread should close the connection (and inform the app) --- Key: AMQ-995 URL: https://issues.apache.org/activemq/browse/AMQ-995 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt Assigned To: james strachan Attachments: amq995-patch.txt, AtomicBoolean.cs If the reader thread throws an exception (e.g. IOException) then the socket should be closed to prevent further messages being sent to the broker. If an exception is thrown during the marshalling of a message then there's no way for the stream to be set to the beginning of the next message, so all communication with the broker should cease at that point. Similarly, if the broker is killed, an IOException will probably be detected in the read thread first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Can I change logger class for MX4J in Geronimo?
Hi, I noticed that mx4j.log.CommonsLogger is hardcoded in org.apache.geronimo.kernel.log.GeronimoLogging class. Can I use another logger class? If yes then how can I do this? Thanks, Nellya Udovichenko
Re: Submitting patches with new files?
Thanks for the response Paul... that makes sense. Why are the most obvious things the hardest to find? ;-)On 10/23/06, Paul McMahan [EMAIL PROTECTED] wrote:Chris,if you check out the src tree using svn then use svn add to add files to your local copy. Then the new files will be in theresulting patch generated when you type svn diff.Best wishes,PaulOn 10/23/06, Christopher Blythe [EMAIL PROTECTED] wrote: What is the best method for submitting a patch that contains new files? From what I have read and seen on my own, the cmd line based subversion diff command does not include them in the resulting patch file. Or, am I missing something? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
AMQ SNAPSHOT download link is still not working
Any one has any idea why people.apache.org is giving a Gateway timeout error when I am trying to click on the latest SNAPSHOT download link? Thanks! Vik
[jira] Created: (AMQ-1000) Networks of Brokers web page has errors
Networks of Brokers web page has errors - Key: AMQ-1000 URL: https://issues.apache.org/activemq/browse/AMQ-1000 Project: ActiveMQ Issue Type: Bug Components: Documentation Reporter: Bernhard Wellhöfer Hello, The page http://incubator.apache.org/activemq/networks-of-brokers.html has two errors: 1) Under NetworkConnector Properties the bridgeTempDestinations property is missing. 2) The examples under Example Configuration using NetworkConnector properties are not valid XML files. The properties name, dynamicOnly, conduitSubscriptions and decreaseNetworkConsumerPriority have to be XML attributes to the networkConnector element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Load driving scripts for Daytrader
Hi all, It is great to have the Daytrader sample in the Geronimo projects. Daytrader is an end-to-end application that allows a full functional testing of Geronimo as well as measuring the performance of the server. However, in order to do a performance test, a users need to drive the application with some kind of a load driving software. And for that they need to spend time and effort to develop scripts for driving the sample. Very often, they do not have the time or the desire to invest in learning all the specifics about a new load driving tool and/or the application just to be able to perform a test. But if they are provided will the scripts they will gladly use them. I think that it would be very useful for both developers and users of Daytrader to package the benchmark with scripts for load driving it. There are a couple of load driving software project in the open source arena that we can use for that purpose. Recently, I looked into a couple of them (for my own testing purposes). I think that the Apache Jackarta JMeter (http://jakarta.apache.org/jmeter/) would be suitable choice for driving Daytrader. Thoughts? Suggestions? Slava
Re: Can I change logger class for MX4J in Geronimo?
I would try to redirect mx4j.log.Logger again as described in http://mx4j.sourceforge.net/docs/ch04s03.html. But what do you want to achieve? Heinz On 10/24/06, Udovichenko, Nellya [EMAIL PROTECTED] wrote: Hi, I noticed that 'mx4j.log.CommonsLogger' is hardcoded in org.apache.geronimo.kernel.log.GeronimoLogging class. Can I use another logger class? If yes then how can I do this? Thanks, Nellya Udovichenko
Re: Load driving scripts for Daytrader
Hi Slava, I agree with your thoughts.Daytrader as a appserver performance test suite is incomplete without having a way to drive load to it. I was contemplating the thought of writing a Java based standalone client to drive it, but haven't done that because of couple of afterthoughts. Firstwas the time required to do that, second writing it in such a way that it remains configurable and extendable to suit different test scenarios. The option of using an opensource load driver is definitely more appealing. Its the learning curve reqd to use them and then coming up with the scripts,but once someone does it for you and gives you a template its easy to take off with it. I am sure we can use the scripts as-is and if need be modify/augment it to suit individual testingneeds. What kind of scenarios have you tested with JMeter? Regards, Piyush Agarwal On 10/24/06, Slava McDougald [EMAIL PROTECTED] wrote: Hi all,It is great to have the Daytrader sample in the Geronimo projects.Daytrader is an end-to-end application that allows a full functional testing of Geronimo as well as measuring the performance of theserver.However, in order to do a performance test, a users need to drive theapplication with some kind of a load driving software.And for that they need to spend time and effort to develop scripts for driving thesample.Very often, they do not have the time or the desire to investin learning all the specifics about a new load driving tool and/or the application just to be able to perform a test.But if they areprovided will the scripts they will gladly use them.I think that it would be very useful for both developers and users ofDaytrader to package the benchmark with scripts for load driving it. There are a couple of load driving software project in the open sourcearena that we can use for that purpose.Recently, I looked into acouple of them (for my own testing purposes).I think that the Apache Jackarta JMeter (http://jakarta.apache.org/jmeter/) would be suitablechoice for driving Daytrader.Thoughts?Suggestions?Slava
Re: Proposing an SSB to JDBC mode for Daytrader
Chris,I'll take a look at the patch you provided. The best way to submit patches is to open a JIRA and attach the patch there. When attaching the patch it will ask you to grant the patch to the ASF. this provides a good trail for copyright info as well as visibility for people tracking the project.On Oct 24, 2006, at 11:05 AM, Christopher Blythe wrote:I know it has been a while since this thread has been visited; however, I finally got a chance to add a "Session Direct" mode to the DayTrader runtime modes. Fortunately, it did not require that many changes to the source. Here is a brief summary of the changes I made...- Added an inSession flag to TradeDirect class. If this flag is true, we skip the transaction management logic- Added similar logic to the KeySequenceDirect class - Created a new session bean (TradeJDBC) which implements the TradeServices interface. Each service method within this session bean creates a new instance of TradeDirect with inSession set to true- Added two additional primitives: PingServlet2Session2JDBC and PingServlet2Session2JDBCCollection I tested the changes out under load without any exceptions. Just for reference, I performed the tests on a 1 x 3.2 GHz Intel Xeon system (connecting to a DB2 database) and noted the following results.Direct Mode: 645 req/sec Session Direct Mode: 119 req/secI have attached a patch file based off of a 10/24/2006 snapshot of daytrader/trunk. If you have any comments, let me know. There are probably some things in there that could be cleaned up (ie. comments, class names, etc.), but I think this does provide a good starting point. Thanks...ChrisOn 7/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think this makes a lot of sense Chris. I assume your adding a third runtime mode as opposed toremoving the ejb mode?I'd like to start thinking about how to rearchitect DT ro be more relevant. I'd like to include a Spring mode as well as update the EJBs to EJB 3.0.Any other thoughts out there?Christopher Blythe wrote: The EJB and Direct modes in Daytrader provide a good measure of how a pure EJB (Session/CMP Entity) application stacks up against a pure JDBC based app. However, one of the things I have felt Trade/Daytrader has always lacked is a middle ground. In my experience, I have neither seen nor heard of a large number of customers out there in the market using the full EJB programming model (Session and Entity beans). I think a more common customer usage scenario is the stateless session bean to JDBC model where the direct JDBC calls are wrapped/managed by the SSB. I have already taken a quick stab at an implementation since all it really requires is a merging of the TradeDirect and TradeBean code. I have most of the operations working on a single client, but haven't performed any load testing yet. Anyway, I wanted to submit the idea to group and see if there were any comments.-- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durdensession_jdbc.patch Matt Hogstrom[EMAIL PROTECTED]
How to get an attachment of a SOAP reques in a jsr181 component?
Hello, I'm Juan. I am still beginner with ServiceMix. I am recieving a SOAP request in a servicemix-http component and giving the request to another jsr181 component (Both are lightweight). My problem is I can not obtain the attachment that the request is carrying, but I can do that with the parameters. public String sendServiceDOCRequest(String url,String codEmp,String text,String dueDate ) That is the function head of the POJO file that I am using in the jsr181 component; as you can see, the three parameters are able to be accessed. But in my web application I also added an attachment to the SOAP message that I can not get in the SM. Could you help me? How can I get an attachment in my POJO? any examples? Thanks -- View this message in context: http://www.nabble.com/How-to-get-an-attachment-of-a-SOAP-reques-in-a-jsr181-component--tf2502337.html#a6975979 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Load driving scripts for Daytrader
If you can get JMeter going that would be great. I did try it and it used an excessive amount of CPU but I may not have had it configured well.On Oct 24, 2006, at 11:22 AM, Piyush Agarwal wrote:Hi all, It is great to have the Daytrader sample in the Geronimo projects. Daytrader is an end-to-end application that allows a full functional testing of Geronimo as well as measuring the performance of the server. However, in order to do a performance test, a users need to drive the application with some kind of a load driving software. And for that they need to spend time and effort to develop scripts for driving the sample. Very often, they do not have the time or the desire to invest in learning all the specifics about a new load driving tool and/or the application just to be able to perform a test. But if they are provided will the scripts they will gladly use them. Matt Hogstrom[EMAIL PROTECTED]
Re: Proposing an SSB to JDBC mode for Daytrader
Thanks Matt... I will go ahead and open the JIRA...On 10/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Chris,I'll take a look at the patch you provided. The best way to submit patches is to open a JIRA and attach the patch there. When attaching the patch it will ask you to grant the patch to the ASF. this provides a good trail for copyright info as well as visibility for people tracking the project. On Oct 24, 2006, at 11:05 AM, Christopher Blythe wrote: I know it has been a while since this thread has been visited; however, I finally got a chance to add a Session Direct mode to the DayTrader runtime modes. Fortunately, it did not require that many changes to the source. Here is a brief summary of the changes I made...- Added an inSession flag to TradeDirect class. If this flag is true, we skip the transaction management logic- Added similar logic to the KeySequenceDirect class - Created a new session bean (TradeJDBC) which implements the TradeServices interface. Each service method within this session bean creates a new instance of TradeDirect with inSession set to true- Added two additional primitives: PingServlet2Session2JDBC and PingServlet2Session2JDBCCollection I tested the changes out under load without any exceptions. Just for reference, I performed the tests on a 1 x 3.2 GHz Intel Xeon system (connecting to a DB2 database) and noted the following results.Direct Mode: 645 req/sec Session Direct Mode: 119 req/secI have attached a patch file based off of a 10/24/2006 snapshot of daytrader/trunk. If you have any comments, let me know. There are probably some things in there that could be cleaned up (ie. comments, class names, etc.), but I think this does provide a good starting point. Thanks...ChrisOn 7/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think this makes a lot of sense Chris.I assume your adding a third runtime mode as opposed to removing the ejb mode?I'd like to start thinking about how to rearchitect DT ro be more relevant.I'd like to include a Spring mode as well as update the EJBs to EJB 3.0.Any other thoughts out there? Christopher Blythe wrote: The EJB and Direct modes in Daytrader provide a good measure of how a pure EJB (Session/CMP Entity) application stacks up against a pure JDBC based app. However, one of the things I have felt Trade/Daytrader has always lacked is a middle ground. In my experience, I have neither seen nor heard of a large number of customers out there in the market using the full EJB programming model (Session and Entity beans). I think a more common customer usage scenario is the stateless session bean to JDBC model where the direct JDBC calls are wrapped/managed by the SSB. I have already taken a quick stab at an implementation since all it really requires is a merging of the TradeDirect and TradeBean code. I have most of the operations working on a single client, but haven't performed any load testing yet. Anyway, I wanted to submit the idea to group and see if there were any comments.-- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden session_jdbc.patch Matt Hogstrom[EMAIL PROTECTED] -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
[jira] Created: (SM-721) maven plugin creates incorrect jbi.xml if multiple name spaces are used
maven plugin creates incorrect jbi.xml if multiple name spaces are used --- Key: SM-721 URL: https://issues.apache.org/activemq/browse/SM-721 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Reporter: James Bradt Priority: Minor the xbean.xml file below is processed via the jbi maven plugin -- ?xml version=1.0? beans xmlns:jsr181=http://servicemix.apache.org/jsr181/1.0; xmlns:demo=urn:servicemix:soap-binding xmlns:test=urn:servicemix:status-test xmlns:km=urn:iconnect:km classpath location./location /classpath jsr181:endpoint pojoClass=soap.SimpleServiceImpl annotations=jsr181 service=demo:simple-JSR-service endpoint=simple-JSR-service-endpoint / jsr181:endpoint service=km:SM-JSR181-service annotations=jsr181 endpoint=SM-JSR181-service-endpoint jsr181:pojo bean class=com.company.product.SMServiceHttpImpl /bean /jsr181:pojo /jsr181:endpoint /beans -- and the resulting jbi.xml is -- ?xml version=1.0 encoding=UTF-8? jbi xmlns=http://java.sun.com/xml/ns/jbi; version=1.0 services xmlns:ns1=urn:servicemix:soap-binding xmlns:ns1=urn:iconnect:km provides interface-name=ns1:simple-JSR-servicePortType service-name=ns1:simple-JSR-service endpoint-name=simple-JSR-service-endpoint/ provides interface-name=ns1:SM-JSR181-servicePortType service-name=ns1:SM-JSR181-service endpoint-name=SM-JSR181-service-endpoint/ /services /jbi -- The problem is that the namespace 'ns1' is defined twice -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Load driving scripts for Daytrader
Hi Piuysh, Writing your own driver is certainly an option but it wouldn't be my preferred option. You are right; it takes a lot of time, efforts, good design and implementation to build a good load driving tool. In my opinion, it is better to just use whatever it is available out in the open source space. Something like JMeter for example has a large community of developers working on improving and supporting it as w ell as a lot of users that can provide hits/feedback on its use. In addition, the source code is available to download and can change according to your needs. That is why I proposed to use the existing load driver instead of developing one from scratch. For my testing, I used just a simple JMeter scripts, mostly for my own educational purposes. However, I am working on creating a more complex JMeter workload script for Daytrader. Once completed, I will share it with you (the Geronimo development community). Then we can work together on changing/improving it and maybe package it with Daytrader sample. Sounds good? Slava On 10/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: If you can get JMeter going that would be great. I did try it and it used an excessive amount of CPU but I may not have had it configured well. On Oct 24, 2006, at 11:22 AM, Piyush Agarwal wrote: Hi all, It is great to have the Daytrader sample in the Geronimo projects. Daytrader is an end-to-end application that allows a full functional testing of Geronimo as well as measuring the performance of the server. However, in order to do a performance test, a users need to drive the application with some kind of a load driving software. And for that they need to spend time and effort to develop scripts for driving the sample. Very often, they do not have the time or the desire to invest in learning all the specifics about a new load driving tool and/or the application just to be able to perform a test. But if they are provided will the scripts they will gladly use them. Matt Hogstrom [EMAIL PROTECTED]
Re: Load driving scripts for Daytrader
Hi Matt, Well, my short evaluation of JMeter confirmed your observation: JMeter is definately not a great performing load driving tool. However, I tried/read about a few other open source load drivers and unfortunately I didn't find anything that performs really well. Since JMeter has the largest and the most active development community that provides a good user's support, I think that we can start using it to drive Daytrader (at least until we find something better). Slava On 10/24/06, Slava McDougald [EMAIL PROTECTED] wrote: Hi Piuysh, Writing your own driver is certainly an option but it wouldn't be my preferred option. You are right; it takes a lot of time, efforts, good design and implementation to build a good load driving tool. In my opinion, it is better to just use whatever it is available out in the open source space. Something like JMeter for example has a large community of developers working on improving and supporting it as w ell as a lot of users that can provide hits/feedback on its use. In addition, the source code is available to download and can change according to your needs. That is why I proposed to use the existing load driver instead of developing one from scratch. For my testing, I used just a simple JMeter scripts, mostly for my own educational purposes. However, I am working on creating a more complex JMeter workload script for Daytrader. Once completed, I will share it with you (the Geronimo development community). Then we can work together on changing/improving it and maybe package it with Daytrader sample. Sounds good? Slava On 10/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: If you can get JMeter going that would be great. I did try it and it used an excessive amount of CPU but I may not have had it configured well. On Oct 24, 2006, at 11:22 AM, Piyush Agarwal wrote: Hi all, It is great to have the Daytrader sample in the Geronimo projects. Daytrader is an end-to-end application that allows a full functional testing of Geronimo as well as measuring the performance of the server. However, in order to do a performance test, a users need to drive the application with some kind of a load driving software. And for that they need to spend time and effort to develop scripts for driving the sample. Very often, they do not have the time or the desire to invest in learning all the specifics about a new load driving tool and/or the application just to be able to perform a test. But if they are provided will the scripts they will gladly use them. Matt Hogstrom [EMAIL PROTECTED]
[jira] Closed: (GERONIMODEVTOOLS-111) Allow project publish order to be controlled by project build order
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-111?page=all ] Sachin Patel closed GERONIMODEVTOOLS-111. - Resolution: Won't Fix Allow project publish order to be controlled by project build order --- Key: GERONIMODEVTOOLS-111 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-111 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 1.x Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Submitting patches with new files?
As a follow up question... what is the best means of handling new and/or updates to binary files when creating a patch? I noticed from one of my diff files something similar to the following...Index: modules/dojo-ui-web/src/main/webapp/storage_dialog.swf ===Cannot display: file marked as a binary type.svn:mime-type = application/octet-streamProperty changes on: modules/dojo-ui-web/src/main/webapp/storage_dialog.swf ___Name: svn:mime-type + application/octet-streamThanks again...ChrisOn 10/24/06, Christopher Blythe [EMAIL PROTECTED] wrote: Thanks for the response Paul... that makes sense. Why are the most obvious things the hardest to find? ;-)On 10/23/06, Paul McMahan [EMAIL PROTECTED] wrote:Chris,if you check out the src tree using svn then use svn add to add files to your local copy. Then the new files will be in theresulting patch generated when you type svn diff.Best wishes,PaulOn 10/23/06, Christopher Blythe [EMAIL PROTECTED] wrote: What is the best method for submitting a patch that contains new files? From what I have read and seen on my own, the cmd line based subversion diff command does not include them in the resulting patch file. Or, am I missing something? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Re: Submitting patches with new files?
Christopher, you can attach the binary files to the same JIRA you attach your patch to. If there are several binary files then you may want to collect them in a zip or tgz first. Best wishes, Paul On 10/24/06, Christopher Blythe [EMAIL PROTECTED] wrote: As a follow up question... what is the best means of handling new and/or updates to binary files when creating a patch? I noticed from one of my diff files something similar to the following... Index: modules/dojo-ui-web/src/main/webapp/storage_dialog.swf === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Property changes on: modules/dojo-ui-web/src/main/webapp/storage_dialog.swf ___ Name: svn:mime-type + application/octet-stream Thanks again... Chris On 10/24/06, Christopher Blythe [EMAIL PROTECTED] wrote: Thanks for the response Paul... that makes sense. Why are the most obvious things the hardest to find? ;-) On 10/23/06, Paul McMahan [EMAIL PROTECTED] wrote: Chris, if you check out the src tree using svn then use svn add to add files to your local copy. Then the new files will be in the resulting patch generated when you type svn diff. Best wishes, Paul On 10/23/06, Christopher Blythe [EMAIL PROTECTED] wrote: What is the best method for submitting a patch that contains new files? From what I have read and seen on my own, the cmd line based subversion diff command does not include them in the resulting patch file. Or, am I missing something? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37277 ] Nikola Goran Cutura commented on AMQ-826: - I finished improvement together with unit test (running on external ADS). There are two assumptions I want to confirm: 1. Composite destinations ACL set of a composite destination is a union of ACL sets of each particular destination. I deduced this from code (DefaultAuthorizationMap) and implemented the same although it does not seem logical to me. Intersection of sets would be more appropriate, I believe. Should I implement the intersection or leave the union? 2. Wildcard destinations Wildcards are given in authorization policy source (xml map or ldap or...) to allow creation (primarily) of a destination in a certain namespace. Wildcard is which means any destination. This meaning is unlimited in depth i.e. ActiveMQ.Advisory. will suffice both for ActiveMQ.Advisory.Connection ( = Connection, same level) and for ActiveMQ.Advisory.Queue.ABC123 ( = Queue.ABC123, one level more). Is this correct? Should I leave it as it is or restrict to the same level only? LDAP based authorization support Key: AMQ-826 URL: https://issues.apache.org/activemq/browse/AMQ-826 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: Nikola Goran Cutura Attachments: LdapAuth.zip Patch kindly added by ngcutura - discussion thread... http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build fails with SVN checkout
Thanks, I did it and it works. I already use it for development but I wanted to build my own AMQ from Maven and it fails. Right now, I build from Eclipse only the modules I actually work on and then use AMQ snapshot with my modules. However, I have another issue: activemq-core requires JDK 1.5 to build. Build fails if I use J2SDK 1.4.2 Is this expected? I can build activemq-jaas with 1.4.2 just fine. Regards, NGC rajdavies wrote: the command you need is mvn eclipse:eclipse - which will build the eclipse .project file for you. What I'd recommend (if your not already doing this) is: 1. build activemq in a separate area from your eclipse workspace - mvn install -Dmaven.test.skip=true 2. build all the eclipse projects - mvn eclipse:eclipse 3. ensure the M2_REPO variable is set in eclipse to your maven repo (usually located in your home directory - called .m2/repository). Your can set the variable from the eclipse properties dialog (ADD variable) 4. Use Eclipse - File - Import - import existing properties into workspace - to import the bits of activemq you want apologies if you already know how to do this! cheers, Rob On 12 Oct 2006, at 12:44, ngcutura wrote: Hi, I am using Eclipse. When I do as you suggested from the command line, I get Build Successful. When start Eclipse again, I have the same errors as before. Any suggestions? Regards, NGC rajdavies wrote: try changing directory to activemq/activemq-openwire-generator - and do mvn install from there - then the build should work from the top directory. Please note - there's some failing test cases at the moment - just fixing ... cheers, Rob On 12 Oct 2006, at 09:28, ngcutura wrote: Hi, Here are the errors Maven reports. I have direct access to the Internet, no proxy. Where can I find the missing files for manual download? Regards, NGC ... 12.10.06. 08.59.54 CEST: Missing: -- 1) com.sun:tools:jar:1.4.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun - DartifactId=tools \ -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.activemq:activemq-openwire-generator:jar:4.1-incubator- SNAPSHOT 2) com.sun:tools:jar:1.4.2 -- 1 required artifact is missing. for artifact: org.apache.activemq:activemq-openwire-generator-4.1-incubator- SNAPSHOT.jar ... 12.10.06. 09.54.13 CEST: Missing: -- 1) com.sun:tools:jar:1.4.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun - DartifactId=tools \ -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.activemq:activemq-openwire-generator:jar:4.1-incubator- SNAPSHOT 2) com.sun:tools:jar:1.4.2 -- 1 required artifact is missing. for artifact: org.apache.activemq:activemq-openwire-generator-4.1-incubator- SNAPSHOT.jar ... 12.10.06. 10.06.18 CEST: Missing: -- 1) com.sun:tools:jar:1.4.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun - DartifactId=tools \ -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.activemq:activemq-openwire-generator:jar:4.1-incubator- SNAPSHOT 2) com.sun:tools:jar:1.4.2 -- 1 required artifact is missing. for artifact: org.apache.activemq:activemq-openwire-generator-4.1-incubator- SNAPSHOT.jar -- View this message in context: http://www.nabble.com/Build-fails- with-SVN-checkout-tf2318351.html#a6772114 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Build-fails- with-SVN-checkout-tf2318351.html#a6774651 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Build-fails-with-SVN-checkout-tf2318351.html#a6981807 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [VOTE] Specs organization, versioning, and releasing
Folks... this vote has been lingering for way to long... some of the
in-flight debate/discussion kinda threw us off track.
I believe that we should implement the solution we have described here
for now and if needed continue discussion and debate about how to
handle this better... BUT, I think we must do something now and I
think that this is good enough.
Here is a tally of the votes cast so far:
snip
+1: jdillon, dblevins, dain, bsnyder, bdudney, gnodet, pmcmahan,
jbohn, rmcguire, hogstrom
+0: jacek
And after some debate:
+1: kevan, alan
/snip
While I, djencks, kevan and a few others have expressed some desire
for one version for all specs, and many other have expressed
objection... I do believe that we need to do something to get specs
into a publishable state NOW.
So, unless anyone screams loudly, I am going to implement the changes
described below as an intermediate solution. Once this is done (and
once people comes back to life) we can publish a new set of SNAPSHOT
artifacts and remove the need for the specs build in bootstrap...
which is one step closer to not needing bootstrap.
This may not be the final solution... but its one step closer... and
since we have not moved at all on this for quite some time I think any
movement is better than none at all.
--jason
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out
as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change
to a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
Re: Load driving scripts for Daytrader
Hello, I think that the Grinder definitively is worth to consider. I have used it a couple of times and I think that it is better than JMeter. Thanks, Gianny On 25/10/2006, at 3:44 AM, Slava McDougald wrote: Hi Matt, Well, my short evaluation of JMeter confirmed your observation: JMeter is definately not a great performing load driving tool. However, I tried/read about a few other open source load drivers and unfortunately I didn't find anything that performs really well. Since JMeter has the largest and the most active development community that provides a good user's support, I think that we can start using it to drive Daytrader (at least until we find something better). Slava On 10/24/06, Slava McDougald [EMAIL PROTECTED] wrote: Hi Piuysh, Writing your own driver is certainly an option but it wouldn't be my preferred option. You are right; it takes a lot of time, efforts, good design and implementation to build a good load driving tool. In my opinion, it is better to just use whatever it is available out in the open source space. Something like JMeter for example has a large community of developers working on improving and supporting it as w ell as a lot of users that can provide hits/feedback on its use. In addition, the source code is available to download and can change according to your needs. That is why I proposed to use the existing load driver instead of developing one from scratch. For my testing, I used just a simple JMeter scripts, mostly for my own educational purposes. However, I am working on creating a more complex JMeter workload script for Daytrader. Once completed, I will share it with you (the Geronimo development community). Then we can work together on changing/improving it and maybe package it with Daytrader sample. Sounds good? Slava On 10/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote: If you can get JMeter going that would be great. I did try it and it used an excessive amount of CPU but I may not have had it configured well. On Oct 24, 2006, at 11:22 AM, Piyush Agarwal wrote: Hi all, It is great to have the Daytrader sample in the Geronimo projects. Daytrader is an end-to-end application that allows a full functional testing of Geronimo as well as measuring the performance of the server. However, in order to do a performance test, a users need to drive the application with some kind of a load driving software. And for that they need to spend time and effort to develop scripts for driving the sample. Very often, they do not have the time or the desire to invest in learning all the specifics about a new load driving tool and/ or the application just to be able to perform a test. But if they are provided will the scripts they will gladly use them. Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] Specs organization, versioning, and releasing
The vote seems to have passed. Go for it!
Regards,
Alan
On Oct 24, 2006, at 3:53 PM, Jason Dillon wrote:
Folks... this vote has been lingering for way to long... some of the
in-flight debate/discussion kinda threw us off track.
I believe that we should implement the solution we have described here
for now and if needed continue discussion and debate about how to
handle this better... BUT, I think we must do something now and I
think that this is good enough.
Here is a tally of the votes cast so far:
snip
+1: jdillon, dblevins, dain, bsnyder, bdudney, gnodet, pmcmahan,
jbohn, rmcguire, hogstrom
+0: jacek
And after some debate:
+1: kevan, alan
/snip
While I, djencks, kevan and a few others have expressed some desire
for one version for all specs, and many other have expressed
objection... I do believe that we need to do something to get specs
into a publishable state NOW.
So, unless anyone screams loudly, I am going to implement the changes
described below as an intermediate solution. Once this is done (and
once people comes back to life) we can publish a new set of SNAPSHOT
artifacts and remove the need for the specs build in bootstrap...
which is one step closer to not needing bootstrap.
This may not be the final solution... but its one step closer... and
since we have not moved at all on this for quite some time I think any
movement is better than none at all.
--jason
On 8/18/06, Jason Dillon [EMAIL PROTECTED] wrote:
PROPOSAL:
1. Each spec will no longer be split up into trunk+branches+tags.
There will instead be one trunk+branches+tags for all specs laid out
as follows:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId-version
specs/branches/
2. Each plugin will continue to have its own version and will be
released independently.
3. The top-level will have it's own version, which will remain
independent. When there is a major configuration change in that pom,
the version will be changed and the pom will be republished.
4. Releasing will be done with the maven release plugin ('mvn
release') and should occur at a stable point after any major change
to a spec module.
5. Change all module directories to match artifactIds.
MOTIVATION:
1. one trunk allows the entire set of specs to be checked out all at
once and built all at once.
* * *
[ ] +1 Allow changes
[ ] 0 No opinion
[ ] -1 No, leave the specs asis (provide rationale)
--jason
Re: Daytrader deployment plans?
The plan d-j-plan.xml attached to http://issues.apache.org/jira/ browse/DAYTRADER-14 actually works for both jetty and tomcat on geronimo trunk since I accidentally committed the DatabaseInitializatioGBean. thanks david jencks On Oct 17, 2006, at 11:50 AM, Christopher Blythe wrote: All... I'm a little confused about the Daytrader deployment plans riddled throughout the source tree and was wondering if someone could clear up my confusion? Under the tags/1.1.0 and branches/1.1 source trees, the tomcat- plan.xml and jetty-plan.xml are located and I have been using these on Geronimo 1.1 without a problem. However, if I look under trunk, these files are no where to be found. Instead, it still looks like the old 1.0 deployment plans are located there. Can anyone clarify? Thanks... Chris
J2EE Management for JEE 5
I’m currently investigating what it would take to update our J2EE Management (JSR 77) implementation for compliance with JEE 5 in Geronimo. Looking at the changes between spec releases 1.0 (June 18, 2002) and 1.1 (June 22, 2006) there are 4 items that changed: 1. JSR77.4.2.1.3 will be/ changed from sequence to/ sequenceNumber - This is just a typo error change. 2. JSR77.3.5.0.1 the deploymentDescriptor attribute must provide a full deployment descriptor based on any partial deployment descriptor plus deployment annotations. 3. JSR77.9.1 J2EE Management CIM. The Managed Object Format (MOF) and UML representation of the model are available from the Distributed Management Task Force (DMTF) web site: http://www.dmtf.org/standards/cim 4. JSR77.9.6 Appendix (CIM - Common Information Model) pages 190-214 removed Here’s the link to the spec change log: http://jcp.org/aboutJava/communityprocess/maintenance/jsr077/JSR77_MR.html My first question is do we even have to update our current JSR 77 implementation to become JEE 5 compliant. If the spec changes are all we need to consider then it looks like only item 2 needs some attention since item 1 is just a typo error correction and items 3 and 4 are related to CIM which we didn’t implement. I’m not even sure if we need to do anything with item 2 like checking for deployment descriptor value. Are there any other changes that I need to consider? Please let me know if I am missing anything. Any suggestions, ideas, and concerns are welcome. Thanks, chris
