Re: [JBoss-dev] Can't build
The 796th reason to switch to a separated build ... Tim Fox wrote: > I'm getting the following after doing a cvs update -C in HEAD and then a > build clean: > > BUILD FAILED > C:\dev\jboss-head\build\build.xml:999: The following error occurred > while execut > ing this line: > C:\dev\jboss-head\build\build-thirdparty.xml:140: A versioning problem > exists: > Component: jboss/jbossxb is at version: 1.0.0.CR4 > but it is also required to be compatible with: > [EMAIL PROTECTED], ver > sion=1.0.0.CR5}, [EMAIL PROTECTED], version=snapshot}] > by: jboss/jbossws14 > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > JBoss-Development mailing list > JBoss-Development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jboss-development > > Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Client - server compatibility
Do we guarantee client-server compatibility between different JBoss revisions? In other words, is a client using 4.0.1 client jars guaranteed to connect without problems to a 4.0.4 server? How about the other way around (4.0.4 client jars to 4.0.1 server )? How about different minor versions (4.0 and 4.1)? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-head-jdk-matrix Build Failed
I know :( [EMAIL PROTECTED] wrote: View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060307203159 BUILD FAILED Ant Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:220: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/build-jboss-common.xml:64: Exit code: 1 See compile.log in Build Artifacts for details. Date of build: 03/07/2006 20:31:59 Time to build: 21 minutes 9 seconds Last changed: 03/07/2006 20:22:56 Last log entry: add manually deployed mbeans to top level DI so that error message is printed out on dependency errors
Re: [JBoss-dev] Long standing JMS Message Inflow testing
http://jira.jboss.com/jira/browse/JBMESSAGING-170 is on the list for the 1.0 release, so it should be done by end of March. Scott M Stark wrote: These two issues currently assigned to Tim: http://jira.jboss.com/jira/browse/JBAS-1434 http://jira.jboss.com/jira/browse/JBMESSAGING-170 have been waiting for quite a while. Are we going to be able to get these resolved for the 4.0.4.GA release due out in a month? Scott Stark VP Architecture & Technology JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Example of how careless handling of AOP pointcut expressions can screw you up good
Yes, it does that. But not for the method name. Bill Burke wrote: FYI, if you refactor code with Intelllij, and have the AOP XML in your classpath, it will discover and change the XML for at least the classname. Ovidiu Feodorov wrote: Yes, that's why I said Tim does a very good job at surrounding the functionality he writes with test cases that check whether the expected good things happen, but also probe for potential bad things. Adding lots of tests has two major benefits: 1. Provide you with a safety mesh. Thicker, the better, it may help you catch problems by exposing random interactions never thought about. Machines to run testsuites are cheap. 2. Help you better understand the functionality you write, help you discover edge cases and potential pitfalls, and quite often help you to find a better way to write the very functionality you're working on. Writing tests increases the development time, but the benefits far exceed the drawbacks. Just think at a production down situation that can have been prevented by having the right (and trivial) test in place. The Messaging project's capital sin is to modify/remove a semantically correct test :) Scott M Stark wrote: I would suspect that the tests simply asserted that someone could be denied access. This is a general failing in the tests I see written. Tests only assert that the expected good things happen. There are not enough tests written to validate that bad behaviors are also constrained to expected and recoverable behaviors. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ovidiu Feodorov Sent: Friday, January 27, 2006 11:44 AM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] Example of how careless handling of AOP pointcut expressions can screw you up good A succinct example of how AOP pointcut expressions without proper tests and/or compile-time check tools can screw you up good: JMS lets you create anonymous message producers, and for this case, security checks must be applied on each message send. The following pointcut expression enforces that: aspect="org.jboss.jms.server.container.SecurityAspect"/> Recently, the ProducerAdvised's send() method name and signature has been changed upon a refactoring: $ cvs diff -r 1.3 -r 1.2 ProducerAdvised.java Index: ProducerAdvised.java === RCS file: /cvsroot/jboss/jboss-jms/src/main/org/jboss/jms/server/endpoint/advised/ ProducerAdvised.java,v retrieving revision 1.3 retrieving revision 1.2 diff -r1.3 -r1.2 ... 68c69 <public void sendMessage(Message message) throws JMSException --- public void send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive) throws JMSException ... As result, no security checks were applied anymore on individual message sends for anonymous producers, leading to a very silent, subtle and potentially dangerous error condition. Praises to Tim for adding test cases that helped us catch the problem on our work benches and not in some customer's production environment. Can the Eclipse AOP plugin help in catching this type of error at refactoring time? Ovidiu --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Example of how careless handling of AOP pointcut expressions can screw you up good
Yes, that's why I said Tim does a very good job at surrounding the functionality he writes with test cases that check whether the expected good things happen, but also probe for potential bad things. Adding lots of tests has two major benefits: 1. Provide you with a safety mesh. Thicker, the better, it may help you catch problems by exposing random interactions never thought about. Machines to run testsuites are cheap. 2. Help you better understand the functionality you write, help you discover edge cases and potential pitfalls, and quite often help you to find a better way to write the very functionality you're working on. Writing tests increases the development time, but the benefits far exceed the drawbacks. Just think at a production down situation that can have been prevented by having the right (and trivial) test in place. The Messaging project's capital sin is to modify/remove a semantically correct test :) Scott M Stark wrote: I would suspect that the tests simply asserted that someone could be denied access. This is a general failing in the tests I see written. Tests only assert that the expected good things happen. There are not enough tests written to validate that bad behaviors are also constrained to expected and recoverable behaviors. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ovidiu Feodorov Sent: Friday, January 27, 2006 11:44 AM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] Example of how careless handling of AOP pointcut expressions can screw you up good A succinct example of how AOP pointcut expressions without proper tests and/or compile-time check tools can screw you up good: JMS lets you create anonymous message producers, and for this case, security checks must be applied on each message send. The following pointcut _expression_ enforces that: Recently, the ProducerAdvised's send() method name and signature has been changed upon a refactoring: $ cvs diff -r 1.3 -r 1.2 ProducerAdvised.java Index: ProducerAdvised.java === RCS file: /cvsroot/jboss/jboss-jms/src/main/org/jboss/jms/server/endpoint/advised/ ProducerAdvised.java,v retrieving revision 1.3 retrieving revision 1.2 diff -r1.3 -r1.2 ... 68c69 <public void sendMessage(Message message) throws JMSException --- public void send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive) throws JMSException ... As result, no security checks were applied anymore on individual message sends for anonymous producers, leading to a very silent, subtle and potentially dangerous error condition. Praises to Tim for adding test cases that helped us catch the problem on our work benches and not in some customer's production environment. Can the Eclipse AOP plugin help in catching this type of error at refactoring time? Ovidiu --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Example of how careless handling of AOP pointcut expressions can screw you up good
A succinct example of how AOP pointcut expressions without proper tests and/or compile-time check tools can screw you up good: JMS lets you create anonymous message producers, and for this case, security checks must be applied on each message send. The following pointcut expression enforces that: aspect="org.jboss.jms.server.container.SecurityAspect"/> Recently, the ProducerAdvised's send() method name and signature has been changed upon a refactoring: $ cvs diff -r 1.3 -r 1.2 ProducerAdvised.java Index: ProducerAdvised.java === RCS file: /cvsroot/jboss/jboss-jms/src/main/org/jboss/jms/server/endpoint/advised/ProducerAdvised.java,v retrieving revision 1.3 retrieving revision 1.2 diff -r1.3 -r1.2 ... 68c69
Re: [JBoss-dev] Assigning JIRA tasks to non-committers
Scott M Stark wrote: The Community Task was instead of creating a new group. If there is a non-committer group it’s a mute point. For the following I don’t see the point of a contributor assignment as the task should not even be created until the issue is to the point of the artifact being ready: - proof of concept. This has to be discussed in the design forum so I don’t see why a jira issue is needed in addition. Because there is a lot of noise in the forums. I have limited control over how discussion threads are being created and how they evolve. A forum thread is an open conversation that hopefully helps define and distill a very clear set of issues that need to be executed. Ex: proof of concept that must do this and that. In my opinion, a design forum thread must end with one (or more) JIRA issues or be wiped out as irrelevant. I would like to be able to control more tightly the tasks that are being generated this way, and associate names with them. (by the way, associated a JIRA task with a trhead this is a forum feature I suggested long ago. JIRA can point to a thread, why not a design thread point to a JIRA issue, but now I am diverging). To conclude the "proof of concept" point, there is an issue (the JIRA task), a deliverable (the prototype or some amount of functionality that has to be implemented) and a person that does the work and doesn't necessarily have to be a contributor. - Testing. What functionality exists for which no testcase exists? If you are just wanting to punt the work of testcase to the community, ok to the extent that this does not mean a test is not written. This is border line broken development in that untested features are being released. Correct. However, I can create a JIRA task for a testcase I thought about but I didn't not implement yet. Another type of testing JIRA tasks I can think of "test X feature on the Y platform while interoperating with the Z thirdparty entity and generate a configuration file tuned for X/Y/Z that will be added to the pre-packaged set of alternate configuration files. The task and the deliverable are clearly defined, and they can be executed by a non-committer. - Provide code examples. Unless this is making it into the project docbook, what use is it? It’s just going to be out of date as time goes by. Messaging comes with a set of "examples", each of them containing a README file and a small number of classes that demonstrate a simple feature: sending/receiving a message to a queue, sending/receiving a message to a topic, deploying an MDB, etc. These examples serve two purposes: give a novice user a starting point with the and serve as a second layer of integration tests, as they can be automated and they are run and must pass on each release. Each "example" has a standard format, and I would be happy to get some of these from the community to include them with the release. Since there are contributors asking "how can I start contributing", I would put a set of this kind of tasks out, ready and up for grabs. They can be assigned immediately and do not imply a significant learning curve to produce. No CVS access is required and there is a very well defined deliverable produced by the task. For a patch, I can see assigning it to someone just so that there is a notion of ownership to prevent duplicate work. Same for a wiki page or article. A patch (in this case is a JIRA "Bug" that sits out there in the open) can be assigned to a non-committer and then be applied to the code base. A more basic jira question is, can jira be setup such that a contributor can assign a task to anyone, but only the contributors show up in the drop down list? If that is allowed let’s set this up and forget the community task and separate contributor group as the distinction and maintenance of the group is questionable to me. The maintentance of the group is the biggest issue, I agree. I don't know what this implies, but if it's a lot of trouble, I guess we can live without it From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ovidiu Feodorov Sent: Thursday, December 29, 2005 10:35 AM To: JBoss Development Subject: [JBoss-dev] Assigning JIRA tasks to non-committers Sometimes it is probably appropriate to assign a JIRA task to somebody who is not a CVS committer. These are cases in which I find this useful: - Creating a proof of concept or a prototype that most likely won't make it into the main code base in its actual form. - Providing patches that will be ultimately applied by a committer to the code base - Testing functionality and specific configurations. - Provide code examples - Write a wiki documentation page or other type of article None of these tasks require their assignee to have committer a
[JBoss-dev] Assigning JIRA tasks to non-committers
Sometimes it is probably appropriate to assign a JIRA task to somebody
who is
not a CVS committer. These are cases in which I find this useful:
- Creating a proof of concept or a
prototype that most likely won't make it into the main code base in its
actual form.
- Providing patches that will be ultimately
applied by a committer to the code base
- Testing functionality and specific
configurations.
- Provide code examples
- Write a wiki documentation page or other
type of article
None of these tasks require their assignee to have committer access
since they don't imply CVS write access. However they would help a
project lead to keep track of who is doing what and administer more
easily work that is done by non-JBoss volunteers.
The current JIRA setup doesn't allow this. In order to enable it, we
will need to add a new group to JIRA ("Contributor" or similar) and
probably a new task type "Community Task" (Scott's idea). Personally I
don't see the usefulness of the last one, I think the existing "Task"
is sufficient. Following the same logic, a "Contributor"
can report an (existing type) "Bug" or can suggest an (existing type)
"Feature Request" and he can be
also assigned to it, pending a patch submission. The patch will be be
applied to CVS by a committer, usually the one who assigned the task to
the contributor.
A project lead should be able to include an user in the project's
"Contributor" group. Again, this DOES NOT implies that the user will be
granted CVS access.
This arrangement could also be a good motivator for volunteers, as they
see their contributions publicly recognized and documented. Being a "Contributor" should be prerequisite of becoming a
"Committer".
Please let me know if you find this useful.
Regards,
Ovidiu
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-93) Callback handler returning a generic Object
[ http://jira.jboss.com/jira/browse/JBREM-93?page=comments#action_12316811 ] Ovidiu Feodorov commented on JBREM-93: -- Yes, I guess I can use getCause() to get the original exception. Is this behaviour documented somewhere, so I can rely on it? Won't it change accross releases? If I didn't look in the code, I had no way of knowing I can do that. Since I wasn't able to find it documentated, I was reluctant to use it. On the other hand, if you have handleCallback() returning an Object, the interface would be much more intuitive. Any chance to include this is any of your upcoming releases? > Callback handler returning a generic Object > --- > > Key: JBREM-93 > URL: http://jira.jboss.com/jira/browse/JBREM-93 > Project: JBoss Remoting > Type: Feature Request > Components: callbacks > Reporter: Ovidiu Feodorov > Assignee: Tom Elrod > Priority: Optional > > > InvokerCallbackHandler.handleCallback() returns void. However, is is able to > throw a HandleCallbackException that ultimately reaches the calling party. > I was wondering if it is a big deal to have handleCallback() returning a > generic Object. This would make the handleCallback()'s semantics more > flexible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-93) Callback handler returning a generic Object
[ http://jira.jboss.com/jira/browse/JBREM-93?page=comments#action_12316478 ] Ovidiu Feodorov commented on JBREM-93: -- or at least have ServerInvokerCallbackHandler.handleCallback() pass along unchanged HandleCallbackExceptions it catches from callBackClient.invoke(internalInvocation, callback.getRequestPayload())? > Callback handler returning a generic Object > --- > > Key: JBREM-93 > URL: http://jira.jboss.com/jira/browse/JBREM-93 > Project: JBoss Remoting > Type: Feature Request > Components: callbacks > Reporter: Ovidiu Feodorov > Assignee: Tom Elrod > Priority: Optional > > > InvokerCallbackHandler.handleCallback() returns void. However, is is able to > throw a HandleCallbackException that ultimately reaches the calling party. > I was wondering if it is a big deal to have handleCallback() returning a > generic Object. This would make the handleCallback()'s semantics more > flexible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-93) Callback handler returning a generic Object
Callback handler returning a generic Object --- Key: JBREM-93 URL: http://jira.jboss.com/jira/browse/JBREM-93 Project: JBoss Remoting Type: Feature Request Components: callbacks Reporter: Ovidiu Feodorov Assigned to: Tom Elrod Priority: Optional InvokerCallbackHandler.handleCallback() returns void. However, is is able to throw a HandleCallbackException that ultimately reaches the calling party. I was wondering if it is a big deal to have handleCallback() returning a generic Object. This would make the handleCallback()'s semantics more flexible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-92) in-VM push callbacks don't work
[ http://jira.jboss.com/jira/browse/JBREM-92?page=comments#action_12316477 ] Ovidiu Feodorov commented on JBREM-92: -- Checked in tentative fix: org.jboss.remoting.transport.local.LocalClientInvoker > in-VM push callbacks don't work > > > Key: JBREM-92 > URL: http://jira.jboss.com/jira/browse/JBREM-92 > Project: JBoss Remoting > Type: Bug > Components: callbacks > Versions: 1.0.2 final > Reporter: Ovidiu Feodorov > Assignee: Tom Elrod > > > When registering a push callback handler with the callback server evertything > seems to go well, the ServerInvokerCallbackHandler proxy is created and > registered on the target server, but when trying to actually call back, the > callback does not reach the callback server. > The client, the callback server and the target server are colocated. > I created a test case that fails: > org.jboss.remoting.callback.push.InVMPushCallbackTestCase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-92) in-VM push callbacks don't work
in-VM push callbacks don't work Key: JBREM-92 URL: http://jira.jboss.com/jira/browse/JBREM-92 Project: JBoss Remoting Type: Bug Components: callbacks Versions: 1.0.2 final Reporter: Ovidiu Feodorov Assigned to: Tom Elrod When registering a push callback handler with the callback server evertything seems to go well, the ServerInvokerCallbackHandler proxy is created and registered on the target server, but when trying to actually call back, the callback does not reach the callback server. The client, the callback server and the target server are colocated. I created a test case that fails: org.jboss.remoting.callback.push.InVMPushCallbackTestCase. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1378) Need tcp configuration variation of the cluster unit tests
[ http://jira.jboss.com/jira/browse/JBAS-1378?page=comments#action_12316437 ] Ovidiu Feodorov commented on JBAS-1378: --- Fixed. tests-clustering-all-stacks generates different test report sets for each stack configuration. > Need tcp configuration variation of the cluster unit tests > -- > > Key: JBAS-1378 > URL: http://jira.jboss.com/jira/browse/JBAS-1378 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Priority: Critical > Fix For: JBossAS-4.0.2 Final > > > We are recommending tcp based jgroups configurations but there are no > variations of the existing unit tests for this. This needs to be addressed > for the 4.0.2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1613) NPE in PersistenceManager.loadFromStorage
[ http://jira.jboss.com/jira/browse/JBAS-1613?page=history ] Ovidiu Feodorov moved JBMESSAGING-24 to JBAS-1613: -- Project: JBoss Application Server (was: JBoss Messaging) Key: JBAS-1613 (was: JBMESSAGING-24) Component: (was: Messaging Core Persistence) Security Level: Public > NPE in PersistenceManager.loadFromStorage > - > > Key: JBAS-1613 > URL: http://jira.jboss.com/jira/browse/JBAS-1613 > Project: JBoss Application Server > Type: Bug > Environment: JBoss 4.0.1sp1, JDK 1.4.2, WinXP > Reporter: d00d ranch > > > I have been testing JBoss Messaging, and ran into an interesting exception on > the server. Our testing of TextMessage worked great. We then went to test > BytesMessage, and received the below exception. This exception occurs when a > Consumer attempts to get a message from the queue. Placing messages into the > queue did not generate an exception. These ByteMessages are 7MB in size. > 15:39:03,467 ERROR [SocketManager] Failed to handle: > org.jboss.mq.il.uil2.msgs.R > eceiveMsg26485067[msgType: m_receive, msgID: 7, error: null] > java.lang.NullPointerException > at > org.jboss.mq.pm.jdbc3.PersistenceManager.loadFromStorage(PersistenceM > anager.java:850) > at > org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:41 > 1) > at > org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:3 > 51) > at > org.jboss.mq.server.MessageReference.getMessage(MessageReference.java > :156) > at > org.jboss.mq.server.BasicQueue.setupMessageAcknowledgement(BasicQueue > .java:881) > at org.jboss.mq.server.BasicQueue.receive(BasicQueue.java:488) > at org.jboss.mq.server.JMSQueue.receive(JMSQueue.java:136) > at org.jboss.mq.server.ClientConsumer.receive(ClientConsumer.java:222) > at > org.jboss.mq.server.JMSDestinationManager.receive(JMSDestinationManag > er.java:673) > at > org.jboss.mq.server.JMSServerInterceptorSupport.receive(JMSServerInte > rceptorSupport.java:226) > at > org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurit > yInterceptor.java:100) > at > org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.jav > a:570) > at > org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:22 > 6) > at > org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocke > tManagerHandler.java:149) > at > org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.j > ava:362) > at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:377) > at > EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExec > utor.java:748) > at java.lang.Thread.run(Thread.java:534) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1612) Sending message re-authenticates user and clears security association
[ http://jira.jboss.com/jira/browse/JBAS-1612?page=history ]
Ovidiu Feodorov moved JBMESSAGING-23 to JBAS-1612:
--
Project: JBoss Application Server (was: JBoss Messaging)
Key: JBAS-1612 (was: JBMESSAGING-23)
Component: (was: JMS Security)
Security Level: Public
> Sending message re-authenticates user and clears security association
> -
>
> Key: JBAS-1612
> URL: http://jira.jboss.com/jira/browse/JBAS-1612
> Project: JBoss Application Server
> Type: Bug
> Environment: JBoss AS 3.2.7
> JDK 1.4.2
> Reporter: eugene75
>
>
> public void testJmsMethod()
> {
> // TRANSACTION BEGINS; org.jboss.security.SecurityAssociation.getSubject()
> returns current Subject
> ApplicationUser appUser... // user object retrieved from current Subject
>
> Context jndiContext = new InitialContext();
> QueueConnectionFactory factory = (QueueConnectionFactory)
> jndiContext.lookup("java:/JmsXA");
> QueueConnection conn = factory.createQueueConnection(appUser.getUserId(),
> appUser.getPassword());
> Queue queue = (javax.jms.Queue) jndiContext.lookup("queue/nameOfQueue");
> QueueSession session = connection.createQueueSession(true,
> Session.AUTO_ACKNOWLEDGE);
> // #1 USER HAS BEEN RE-AUTHENTICATED (new JAAS subject)
> QueueSender sender = session.createSender(queue);
> MapMessage message = session.createMapMessage();
> sender.send(message);
> conn.close();
> }
> // #2 TRANSACTION COMPLETES;
> org.jboss.security.SecurityAssociation.getSubject() returns null
> #1. User is re-authenticated -- even though the username and credential are
> for the current user -- ecause the JaasSecurity.validateCache method returns
> false. The method does so because the web layer stores the user credential
> as a String, so the cached DomainInfo.credential is a string; but the
> SpyXAConnection calls JaasSecurityManager.isValid using a char[] as the
> credential. Cache validation will never consider char[] and String to be
> equivalent even if the underlying character sequence is identical.
> #2. Security association for the thread has been cleared. This appears to
> happen when the transaction completes, indicating it is done by a
> Synchronization listener. Normally, the security association is cleared by
> the SecurityAssociation valve in Tomcat.
> Workarounds are possible by ensuring that any JMS message sending is the
> absolute last thing that occurs during a request, but this is not optimal.
> The re-authentication also discards information stored in the Subject that
> was added after the login process.
> It would be helpful is JBoss would choose a standard format for user
> credentials so as to prevent this problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1611) ClientMonitorIntecepor
[ http://jira.jboss.com/jira/browse/JBAS-1611?page=history ]
Ovidiu Feodorov moved JBMESSAGING-21 to JBAS-1611:
--
Project: JBoss Application Server (was: JBoss Messaging)
Key: JBAS-1611 (was: JBMESSAGING-21)
Component: (was: JMS Destination Manager)
Security Level: Public
> ClientMonitorIntecepor
> --
>
> Key: JBAS-1611
> URL: http://jira.jboss.com/jira/browse/JBAS-1611
> Project: JBoss Application Server
> Type: Bug
> Reporter: Alex
>
>
> If client used HTTPConnection (HTTPConnectionFactory) to subscribe to the
> nondurable topic and client don't receive messages during ClientTimeout time
> ClientMonitorIntecepor (if it running) close connection for it, because http
> connection is stateles and client don't ping server even I set PingPeriod for
> http connection to some value difference from 0, and
> "getClientStats(dc).lastUsed" value udate only if client receive any message
> from the server.
> In the source code of HTTPILService the PingPeriod value set to the 0,
> and client never send ping message to the server.
> It's HTTPILService.startService source:
> public void startService() throws Exception
>{
> super.startService();
> this.pingPeriod = 0;// We don't do pings.
> ...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1378) Need tcp configuration variation of the cluster unit tests
[ http://jira.jboss.com/jira/browse/JBAS-1378?page=comments#action_12316280 ] Ovidiu Feodorov commented on JBAS-1378: --- Running the same test twice overrides the first results so the report is incomplete. Do you know how to fix this easily or you want me to look into it? > Need tcp configuration variation of the cluster unit tests > -- > > Key: JBAS-1378 > URL: http://jira.jboss.com/jira/browse/JBAS-1378 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Priority: Critical > Fix For: JBossAS-4.0.2 Final > > > We are recommending tcp based jgroups configurations but there are no > variations of the existing unit tests for this. This needs to be addressed > for the 4.0.2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1378) Need tcp configuration variation of the cluster unit tests
[ http://jira.jboss.com/jira/browse/JBAS-1378?page=history ] Ovidiu Feodorov resolved JBAS-1378: --- Resolution: Done Modified files: cluster/src/etc/cluster-service.xml, tomcat/src/resources/tc5-cluster-service.xml, testsuite/build.xml, testsuite/imports/server-config.xml However, some of the clustering tests were failing to start with (2 errors and 28 failures out of 64 tests) but this should be probably the subject of another JIRA task. > Need tcp configuration variation of the cluster unit tests > -- > > Key: JBAS-1378 > URL: http://jira.jboss.com/jira/browse/JBAS-1378 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Priority: Critical > Fix For: JBossAS-4.0.2 Final > > > We are recommending tcp based jgroups configurations but there are no > variations of the existing unit tests for this. This needs to be addressed > for the 4.0.2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1378) Need tcp configuration variation of the cluster unit tests
[
http://jira.jboss.com/jira/browse/JBAS-1378?page=comments#action_12316240 ]
Ovidiu Feodorov commented on JBAS-1378:
---
The current clustering target ("tests-clustering" of testsuite/build.xml) works
by creating two server configuration node0 and node1, which both use the
default UDP clustering stack (all/deploy/cluster-service.xml)
The way I would introduce a TCP-based clustering test is the following:
1. Add to all/deploy/cluster-service.xml an alternate TCP-based configuration.
By default it will be commented out, but it will contain a well-configured TCP
stack. People could actually uncomment it and use it in production, as is, or
tweak around it.
2. Rewrite the current "tests-clustering" taks to accept a "stack" parameter,
whose possible values are currently "udp" and "tcp". We could add more later.
The task will create the apropriate configurations on disk.
3. The top clustering test target will look something like:
Please let me know if this is what you had in mind when you created this task.
> Need tcp configuration variation of the cluster unit tests
> --
>
> Key: JBAS-1378
> URL: http://jira.jboss.com/jira/browse/JBAS-1378
> Project: JBoss Application Server
> Type: Bug
> Components: Clustering
> Reporter: Scott M Stark
> Assignee: Bela Ban
> Priority: Critical
> Fix For: JBossAS-4.0.2 Final
>
>
> We are recommending tcp based jgroups configurations but there are no
> variations of the existing unit tests for this. This needs to be addressed
> for the 4.0.2 release.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1378) Need tcp configuration variation of the cluster unit tests
[ http://jira.jboss.com/jira/browse/JBAS-1378?page=history ] Ovidiu Feodorov reassigned JBAS-1378: - Assign To: Ovidiu Feodorov (was: Bela Ban) > Need tcp configuration variation of the cluster unit tests > -- > > Key: JBAS-1378 > URL: http://jira.jboss.com/jira/browse/JBAS-1378 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Priority: Critical > Fix For: JBossAS-4.0.2 Final > > > We are recommending tcp based jgroups configurations but there are no > variations of the existing unit tests for this. This needs to be addressed > for the 4.0.2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [Design of JBoss Admin Console] - What to work on
Hey Steve, Have you had a chance to attend the messaging presentation? There was a big "Help wanted" slide in the end http://www.jboss.org/wiki/Wiki.jsp?page=JBossMessaging Regards, Ovidiu spiritualmechanic wrote: Hey Charles, What stuff should I work on if I do something. The JMS stuff? Or what? I sort of want to work on JCA but it looks like your metadata is probably the best way to do it. I've been away for a while but I went to JBoss World 2005 and so I'm psyched to do something, even if it's small. Steve View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3868892#3868892 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3868892 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1027) HA-JNDI binding replicants not initialized properly
[ http://jira.jboss.com/jira/browse/JBAS-1027?page=history ] Ovidiu Feodorov resolved JBAS-1027: --- Resolution: Cannot Reproduce Bug Fix Version: JBossAS-3.2.8 Final I performed the following test on the Branch_3_2 (3.2 head): 1. Start the cluster node "polaris". The ClusterPartition configuration is listed below: This is a TCP-based stack and the multicast discovery is disabled (TCPPING knows the other menber of the cluster) 2. Connect with a JNDI client to the HAJNDI service running on polaris and bind "Polaris -> PayloadOne" into the HAJNDI context. The content of the jndi.properties of the JNDI client is listed below: java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://polaris:1100 java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces jnp.disableDiscovery=true The client-side JNDI autodiscovery is explicitely disabled, so the JNDI client will connect only to the HANamingService running on polaris. 3. List the content of the cluster-wide HAJNDI context. The result is: Polaris -> PayloadOne 4. Start the second cluster node "gatecrasher". The ClusterPartition configuration is listed below: 5. Connect with a JNDI client with the JNDI auto-discovery disabled to the HANamingService of the second node of the cluster (jndi.properties listed below: java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://gatecrasher:1100 java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces jnp.disableDiscovery=true) and list the HAJNDI context. The result is Polaris -> PayloadOne which shows that the bindings owned by the HAJNDI service on the first node of the cluster have been transferred to the HAJNDI service of the second node of the cluster. No patch was applied and no merge procedure was initiated by the HAJNDI code. I don't have enough information to draw a conclusion as why the patch was necessary in your case, but I suspect an incorectly configured JGroups TCP stack. If you want me to analyze the problem further, please attach your JGroups TCP stack configuration and your jndi.properties used by your test clients. A test that fails would be really appreciated. > HA-JNDI binding replicants not initialized properly > --- > > Key: JBAS-1027 > URL: http://jira.jboss.com/jira/browse/JBAS-1027 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assignee: Ovidiu Feodorov > Fix For: JBossAS-3.2.8 Final > > > SourceForge Submitter: mondrejko . > JBoss: 3.2.5 > OS: Windows 2000, Redhat Linux, Solaris 8/9 > HA-JNDI binding replicants not initialized properly when > defining cluster using TCP as the base for the > javagroups stack and disabling all auto-discovery. > I defined a cluster of two nodes using TCP and disabled > node auto-discovery on both the server and client. > Consequently, binding replicants must be explicitly > shared among the cluster nodes. This appears to > function properly for existing nodes when a new node > joins the cluster (that is, the existing node replicants are > updated for the bindings of the new node). However, > the new node replicants are not updated with the > bindings from the existing nodes. Therefore, when a > client connects to this new node of the cluster, the > client does not receive the propery replicants and load > balancing and failover do not function properly. > A 3.2.5 patch to DistributedReplicationManagerImpl.java > for a potential solution has been attached. With this > patch, clustering with TCP and without auto-discovery > works beautifully. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-896) JMS started on both nodes in cluster after network glitch
[ http://jira.jboss.com/jira/browse/JBAS-896?page=history ] Ovidiu Feodorov reassigned JBAS-896: Assign To: Ovidiu Feodorov (was: Bela Ban) > JMS started on both nodes in cluster after network glitch > - > > Key: JBAS-896 > URL: http://jira.jboss.com/jira/browse/JBAS-896 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assignee: Ovidiu Feodorov > > > SourceForge Submitter: iankenn . > Original posting on JBoss.org Clustering forum: > Hi > I'm currently developing a system which uses JMS > queuing for async processing of messages. I'm looking > at deploying to a cluster of two JBoss 3.2.3 servers to > provide some level of fail-over/resilience. > During testing of the JMS fail-over I've tried killing > one of the JBoss instances (the one running the JMS > server) and see that the JMS queues are migrated to the > other node. But when I tried to simulate a temporary > loss of network connectivity between the two machines > (by removing one of the network cables and then > replacing it) the cluster seems to break and both > machines start to run the JMS queues. > When the network cable is reconnected, neither node > appear to know that there is another node in the same > partition. Effectively the cluster is not > re-established. The only way to make the two nodes see > each other again is to restart one of the nodes. Is > there something that I have miss-configured/not > configured, I am new to clustering and would appreciate > some advice. - I am currently testing on two windows > machines but intend to deploy to Linux boxes. > Thanks, > Ian > See posting > http://www.jboss.org/index.html?module=bb&op=viewtopic&t=45901 > Configuration (both machines) > OS: Windows 2000 > JDK: 1.4.2_03 > JBoss: 3.2.3 > The attached zip contains the cluster.log files for > both servers: > Node 'A' - Node_A_cluster.log > Node 'B' - Node_B_cluster.log > Steps > - > 1. Turn on logging for clustering in /conf/log4j.xml > 2. Start JBoss on Node 'A' > 3. Start JBoss on Node 'B' > 4. Deploy EAR to farm dir on Node 'A'' > This is farmed to Node 'B' > 5. Submit Msg to Node 'A' (Http request to application) > 6. Submit Msg to Node 'B' (Http request to application) > 7. Look at the HAILSharedState ServerAddress for the > JBoss MQ on the jmx-console - this shows the IP address > of Node 'A' on both nodes. > 8. Remove network cable from Node 'A' > 9. The following messages are displayed in the console: > Node 'A' > 10:40:53,921 INFO [DefaultPartition] New cluster view > (id: 2, delta: -1) : [192.168.0.34:1099] > 10:40:53,921 INFO [DefaultPartition:ReplicantManager] > Dead members: 1 > 10:40:58,015 INFO [DefaultPartition] Suspected member: > wizcom-desk01:4950 (additional data: 17 byte > s) > Node 'B' > 10:40:53,376 INFO [DefaultPartition] New cluster view > (id: 2, delta: -1) : [192.168.0.46:1099] > 10:40:53,376 INFO [DefaultPartition:ReplicantManager] > Dead members: 1 > 10:40:53,516 INFO [HAILServerILService] Notified to > become singleton > 10. The jmx-console on Node 'B' now shows it's own IP > address as the HAILSharedState ServerAddress. > 11. The jmx-console on Node 'A' still shows it's own IP > address as the HAILSharedState ServerAddress. > 11. Reconnect the network cable to Node 'A' > 12. The following message appears in the console: > Node 'A' > 10:45:05,171 INFO [DefaultPartition] New cluster view > (id: 3, delta: 1) : [192.168.0.34:1099, 192.168.0.46:1099] > 10:45:05,171 INFO [DefaultPartition:ReplicantManager] > Merging partitions... > 10:45:05,171 INFO [DefaultPartition:ReplicantManager] > Dead members: 0 > 10:45:05,187 INFO [DefaultPartition:ReplicantManager] > Originating groups: [[wizcom-comp2:1277 (additional > data: 17 bytes)|2] [wizcom-comp2:1277 (additional data: > 17 bytes)], [wizcom-desk01:4950 (additional data: 17 > bytes)|2] [wizcom-desk01:4950 (additional data: 17 bytes)]] > 10:45:05,233 INFO [DefaultPartition:ReplicantManager] > Start merging members in DRM service... > 10:45:05,655 INFO [DefaultPartition:ReplicantManager] > ..Finished merging members in DRM service > Node 'B' > 10:45:05,740 INFO [DefaultPartition] New cluster view: > 3 ([192.168.0.34:1099, 192.168.0.46:1099] delta: 1) > 10:45:05,756 INFO [DefaultPartition:R
[JBoss-dev] [JBoss JIRA] Closed: (JGRP-42) MethodCall doesn't correctly handle inheritance
[ http://jira.jboss.com/jira/browse/JGRP-42?page=history ] Ovidiu Feodorov closed JGRP-42: --- Resolution: Done org.jgroups.blocks.MethodCall was updated to walk the class hierarchy and locate method not only in the current class, but also in the superclasses and superinterfaces. There is a new test that contains use cases: tests/junit/org/jgroups/blocks/MethodCallTest.java > MethodCall doesn't correctly handle inheritance > --- > > Key: JGRP-42 > URL: http://jira.jboss.com/jira/browse/JGRP-42 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Reporter: Ovidiu Feodorov > Assignee: Ovidiu Feodorov > Fix For: 2.2.8 > > > A MethodCall containing a method from a base class fails to invoke correctly > on an instance of a derived class. > Sample error message: 2005-02-18 08:59:21,551 ERROR > [org.jgroups.blocks.MethodCall] found no method called > _receiveRemoteNotification in class > org.jboss.ha.singleton.HASingletonController with > (javax.management.AttributeChangeNotification) formal parameters . > In the example above, the HASingletonController class does not declare > _receiveRemoteNotification(), but one of its ancestors does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-42) MethodCall doesn't correctly handle inheritance
[ http://jira.jboss.com/jira/browse/JGRP-42?page=history ] Ovidiu Feodorov updated JGRP-42: Description: A MethodCall containing a method from a base class fails to invoke correctly on an instance of a derived class. Sample error message: 2005-02-18 08:59:21,551 ERROR [org.jgroups.blocks.MethodCall] found no method called _receiveRemoteNotification in class org.jboss.ha.singleton.HASingletonController with (javax.management.AttributeChangeNotification) formal parameters . In the example above, the HASingletonController class does not declare _receiveRemoteNotification(), but one of its ancestors does. was: A MethodCall containing a method from a base class fails to invoke correctly on an instance of a derived class. Sample error message: 2005-02-18 08:59:21,551 ERROR [org.jgroups.blocks.MethodCall] found no method called _receiveRemoteNotification in class org.jboss.ha.singleton.HASingletonController with (javax.management.AttributeChangeNotification) formal parameters . In the example above, the HASingletonController class does not declare_receiveRemoteNotification(), but one of its ancestors does. > MethodCall doesn't correctly handle inheritance > --- > > Key: JGRP-42 > URL: http://jira.jboss.com/jira/browse/JGRP-42 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Reporter: Ovidiu Feodorov > Assignee: Ovidiu Feodorov > Fix For: 2.2.8 > > > A MethodCall containing a method from a base class fails to invoke correctly > on an instance of a derived class. > Sample error message: 2005-02-18 08:59:21,551 ERROR > [org.jgroups.blocks.MethodCall] found no method called > _receiveRemoteNotification in class > org.jboss.ha.singleton.HASingletonController with > (javax.management.AttributeChangeNotification) formal parameters . > In the example above, the HASingletonController class does not declare > _receiveRemoteNotification(), but one of its ancestors does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-42) MethodCall doesn't correctly handle inheritance
[ http://jira.jboss.com/jira/browse/JGRP-42?page=history ] Ovidiu Feodorov updated JGRP-42: Description: A MethodCall containing a method from a base class fails to invoke correctly on an instance of a derived class. Sample error message: 2005-02-18 08:59:21,551 ERROR [org.jgroups.blocks.MethodCall] found no method called _receiveRemoteNotification in class org.jboss.ha.singleton.HASingletonController with (javax.management.AttributeChangeNotification) formal parameters . In the example above, the HASingletonController class does not declare_receiveRemoteNotification(), but one of its ancestors does. was: A MethodCall containing a method from a base class fails to invoke correctly on an instance of a derived class. Sample error message: 2005-02-18 08:59:21,551 ERROR [org.jgroups.blocks.MethodCall] found no method called _receiveRemoteNotification in class org.jboss.ha.singleton.HASingletonController with (javax.management.AttributeChangeNotification) formal parameters . In the example above, the HASingletonController class does not declare_receiveRemoteNotification(), but one of its ancestors do. > MethodCall doesn't correctly handle inheritance > --- > > Key: JGRP-42 > URL: http://jira.jboss.com/jira/browse/JGRP-42 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Reporter: Ovidiu Feodorov > Assignee: Ovidiu Feodorov > Fix For: 2.2.8 > > > A MethodCall containing a method from a base class fails to invoke correctly > on an instance of a derived class. > Sample error message: 2005-02-18 08:59:21,551 ERROR > [org.jgroups.blocks.MethodCall] found no method called > _receiveRemoteNotification in class > org.jboss.ha.singleton.HASingletonController with > (javax.management.AttributeChangeNotification) formal parameters . > In the example above, the HASingletonController class does not > declare_receiveRemoteNotification(), but one of its ancestors does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-42) MethodCall doesn't correctly handle inheritance
MethodCall doesn't correctly handle inheritance --- Key: JGRP-42 URL: http://jira.jboss.com/jira/browse/JGRP-42 Project: JGroups Type: Bug Versions: 2.2.8 Reporter: Ovidiu Feodorov Assigned to: Bela Ban Fix For: 2.2.8 A MethodCall containing a method from a base class fails to invoke correctly on an instance of a derived class. Sample error message: 2005-02-18 08:59:21,551 ERROR [org.jgroups.blocks.MethodCall] found no method called _receiveRemoteNotification in class org.jboss.ha.singleton.HASingletonController with (javax.management.AttributeChangeNotification) formal parameters . In the example above, the HASingletonController class does not declare_receiveRemoteNotification(), but one of its ancestors do. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Assigned: (JGRP-42) MethodCall doesn't correctly handle inheritance
[ http://jira.jboss.com/jira/browse/JGRP-42?page=history ] Ovidiu Feodorov reassigned JGRP-42: --- Assign To: Ovidiu Feodorov (was: Bela Ban) > MethodCall doesn't correctly handle inheritance > --- > > Key: JGRP-42 > URL: http://jira.jboss.com/jira/browse/JGRP-42 > Project: JGroups > Type: Bug > Versions: 2.2.8 > Reporter: Ovidiu Feodorov > Assignee: Ovidiu Feodorov > Fix For: 2.2.8 > > > A MethodCall containing a method from a base class fails to invoke correctly > on an instance of a derived class. > Sample error message: 2005-02-18 08:59:21,551 ERROR > [org.jgroups.blocks.MethodCall] found no method called > _receiveRemoteNotification in class > org.jboss.ha.singleton.HASingletonController with > (javax.management.AttributeChangeNotification) formal parameters . > In the example above, the HASingletonController class does not > declare_receiveRemoteNotification(), but one of its ancestors do. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-39) A TCP stack does not correctly detect failure (pulled cable) for certain TCPPING configurations
[ http://jira.jboss.com/jira/browse/JGRP-39?page=comments#action_12315516 ] Ovidiu Feodorov commented on JGRP-39: - FD_SOCK has a different problem, the pulled cable is only detected after a long time, and even when it is detected, the stack does not behave correctly. More testing needed. > A TCP stack does not correctly detect failure (pulled cable) for certain > TCPPING configurations > --- > > Key: JGRP-39 > URL: http://jira.jboss.com/jira/browse/JGRP-39 > Project: JGroups > Type: Bug > Versions: 2.2.9 > Reporter: Ovidiu Feodorov > Assignee: Ovidiu Feodorov > Fix For: 2.2.8 > > > Physical hosts "A" (192.168.1.1, coordinator) and "B" (192.168.1.2) run > JGroups processes configured with TCP/TCPPING stacks. > "A" stack configuration: > TCP(bind_addr=192.168.1.1;start_port=11800;loopback=true): > TCPPING(initial_hosts=192.168.1.2[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): > MERGE2(min_interval=5000;max_interval=1): > FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): > pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false): > pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) > "B" stack configuration: > TCP(bind_addr=192.168.1.2;start_port=11800;loopback=true): > TCPPING(initial_hosts=192.168.1.1[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): > MERGE2(min_interval=5000;max_interval=1): > FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): > VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): > pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): > pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false): > pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) > If I pull the cable under B, the B stack immediately and correctly > indentifies A as suspect and installs a new view containing itself only. > However, A does not recognizes B as suspect and undeterministically spews out > various info and warning messages. The view (A, B) stays incorrectly "valid" > for a long time; sometimes gets replaced by (A), sometimes not. > I tracked down the cause of the problem down to the A TCPPING configuration > and TCP queue . If A's TCPPING is configured with a port_range=1, the > problem goes away and the new view immediately installs into the A stack. It > seems that if there are messages in the TCP queue except the SUSPECT message > generated by FD, they mess up things and the SUSPECT message gets stuck in > the queue, with undeterministic results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-39) A TCP stack does not correctly detect failure (pulled cable) for certain TCPPING configurations
A TCP stack does not correctly detect failure (pulled cable) for certain TCPPING configurations --- Key: JGRP-39 URL: http://jira.jboss.com/jira/browse/JGRP-39 Project: JGroups Type: Bug Versions: 2.2.9 Reporter: Ovidiu Feodorov Assigned to: Bela Ban Physical hosts "A" (192.168.1.1, coordinator) and "B" (192.168.1.2) run JGroups processes configured with TCP/TCPPING stacks. "A" stack configuration: TCP(bind_addr=192.168.1.1;start_port=11800;loopback=true): TCPPING(initial_hosts=192.168.1.2[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): MERGE2(min_interval=5000;max_interval=1): FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false): pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) "B" stack configuration: TCP(bind_addr=192.168.1.2;start_port=11800;loopback=true): TCPPING(initial_hosts=192.168.1.1[11800];port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true): MERGE2(min_interval=5000;max_interval=1): FD(shun=true;timeout=1500;max_tries=3;up_thread=true;down_thread=true): VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false): pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000): pbcast.STABLE(desired_avg_gossip=2;down_thread=false;up_thread=false): pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false;down_thread=true;up_thread=true) If I pull the cable under B, the B stack immediately and correctly indentifies A as suspect and installs a new view containing itself only. However, A does not recognizes B as suspect and undeterministically spews out various info and warning messages. The view (A, B) stays incorrectly "valid" for a long time; sometimes gets replaced by (A), sometimes not. I tracked down the cause of the problem down to the A TCPPING configuration and TCP queue . If A's TCPPING is configured with a port_range=1, the problem goes away and the new view immediately installs into the A stack. It seems that if there are messages in the TCP queue except the SUSPECT message generated by FD, they mess up things and the SUSPECT message gets stuck in the queue, with undeterministic results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Moved: (JBMQ-105) NullPointerException in JDBC3 PersistenceManager
[ http://jira.jboss.com/jira/browse/JBMQ-105?page=history ] Ovidiu Feodorov moved JBMESSAGING-11 to JBMQ-105: - Project: JBoss MQ (was: JBoss Messaging) Key: JBMQ-105 (was: JBMESSAGING-11) > NullPointerException in JDBC3 PersistenceManager > > > Key: JBMQ-105 > URL: http://jira.jboss.com/jira/browse/JBMQ-105 > Project: JBoss MQ > Type: Bug > Environment: JBoss 4.0.1 (why isn't this an option in the Version list?) > Reporter: Tim McCune > Priority: Critical > > > http://cvs.sourceforge.net/viewcvs.py/jboss/jbossmq/src/main/org/jboss/mq/pm/jdbc3/PersistenceManager.java?r1=1.6.4.1&r2=1.6.4.2 > ejort removed the line > rs = stmt.executeQuery(); > so line 850 of PersistenceManager will always throw an NPE: > Caused by: java.lang.NullPointerException > at > org.jboss.mq.pm.jdbc3.PersistenceManager.loadFromStorage(PersistenceManager.java:850) > at > org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:411) > at > org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:351) > at > org.jboss.mq.server.MessageReference.getMessage(MessageReference.java:156) > at > org.jboss.mq.server.MessageReference.getHeaders(MessageReference.java:249) > at org.jboss.mq.server.BasicQueue.receive(BasicQueue.java:471) > at org.jboss.mq.server.JMSQueue.receive(JMSQueue.java:136) > I'm assuming this was just a slip-up and not intentional. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JMS on JBoss (JMS/JBoss)] - JBoss Messaging project page
OK, but even so http://jboss.org/products/list must be changed: 1. JBoss Messaging should be renamed JBossMQ as we're switching it to maintenance mode. The Forum and Wiki links are appropriate, they point to the user forum and the MQ wiki. 2. A new JBoss Messaging project should be created, with [Forums], [Wiki], [Documentation] and [Downloads] links. The wiki and the forums should point to Mess' development links, and downloads and documentation should get their content soon (JBoss Messaging is supposed to work standalone too). Thanks, Ovidiu Ivelin Ivanov wrote: Top level pages at www.jboss.com are controlled by marketing. They are being revisited. Only products will have direct presence. Projects will have own identity when JBossLabs is ready in Q1. For now, you can use a Wiki page and I can link to it from the projects page http://jboss.org/products/list. Ivelin From: Ovidiu Feodorov Sent: Monday, December 20, 2004 3:33 PM To: Ivelin Ivanov Subject: JBoss Messaging project page Hi Ivelin, I would like to get a top level JBoss Messaging project page going, the same as for JBossCache. I do not have sufficient permissions to modify the site, nor I know how to do it.
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-35) InvalidDestinationException after Cluster Master failover
[ http://jira.jboss.com/jira/browse/JBAS-35?page=comments#action_12310889 ] Ovidiu Feodorov commented on JBAS-35: - For both 4.0.0 and 4.0.1RC2 I deployed a simple singleton that makes it obvious in the logs when it is started and stopped. I tried the following scenarios (for both versions): - Orderly shut down (Ctrl-C). - Disabled the network interface on the master and then re-enabled it. - Pulled the network cable on the master and then re-connected it. I all six cases, the singleton was undeployed/deployed correctly, the healed partition running just only one singleton in the end. That doesn't prove too much tough, an unforeseen race condition is always possible. I could spend more time analyzing the theroretical algorithm the master election is based upon ... The new JBoss Messaging won't use a singleton anymore, but we must have a reliable generic singleton mechanism. > InvalidDestinationException after Cluster Master failover > - > > Key: JBAS-35 > URL: http://jira.jboss.com/jira/browse/JBAS-35 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Versions: JBossAS-3.2.5 Final > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Fix For: JBossAS-3.2.6 Final > Attachments: JBossFailOverError.txt > > > See the attachment JBossFailOverError.txt for more details. > Abstract: I have a 2 node cluster running JbossMQHA. If the Master node is > disconnect from the Network, the slave assumes the master role. But when the > original Master comes back on-line, it reassumes the Master role, but my > subscriber is never notified of the 2nd fail-over and I am unable to publish > on the slave for about 5 minutes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-35) InvalidDestinationException after Cluster Master failover
[ http://jira.jboss.com/jira/browse/JBAS-35?page=comments#action_12310813 ] Ovidiu Feodorov commented on JBAS-35: - The current clustering code (as per 3.2.7) allows the situation when two singleton instances could become active simultaneously in a partition. A sequence that leads to this situation is described below: 1. The node A boots up and starts the singleton instance S1. 2. The node B joins the partition, acknowledges and use S1. 3. Node A is physically disconnected from the network (by pulling the network cable or shuting down the network interface). 4. The A's clustering layer IS NOT aware of disconnection (even if JGroups generates warnings in the log) (TODO - find out why). A continues to run S1. 5. Node B detects A's failure (via JGroups' FD layer) and updates the DRM replicant map. The HASingletonDeployer is notified and deploys the singleton instance S2. 6. Node A is physically re-connected. 7. Node A initiates a partition merge, but still thinks that S1 is master. 8. Node B initates a partition merge and it also thinks that S2 is master. A possible solution is to call _stopOldMaster() across the cluster in HASingletonSupport.partitionTopologyChanged() when the node that is already master becomes aware that is elected new master. This will insure the fact that only one singleton "survives". However, I have not considered all possible cases yet, it is still work in progress. Another possible solution is to maintain the the "master" state in the DRM's replicant map. This issue is still work in progress. > InvalidDestinationException after Cluster Master failover > - > > Key: JBAS-35 > URL: http://jira.jboss.com/jira/browse/JBAS-35 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Versions: JBossAS-3.2.5 Final > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Fix For: JBossAS-3.2.7 Final > Attachments: JBossFailOverError.txt > > > See the attachment JBossFailOverError.txt for more details. > Abstract: I have a 2 node cluster running JbossMQHA. If the Master node is > disconnect from the Network, the slave assumes the master role. But when the > original Master comes back on-line, it reassumes the Master role, but my > subscriber is never notified of the 2nd fail-over and I am unable to publish > on the slave for about 5 minutes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBAS-35) InvalidDestinationException after Cluster Master failover
[ http://jira.jboss.com/jira/browse/JBAS-35?page=history ] Ovidiu Feodorov closed JBAS-35: --- Resolution: Done Fix Version: JBossAS-3.2.6 Final (was: JBossAS-3.2.7 Final) Issue fixed in 3.2.6. > InvalidDestinationException after Cluster Master failover > - > > Key: JBAS-35 > URL: http://jira.jboss.com/jira/browse/JBAS-35 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Versions: JBossAS-3.2.5 Final > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Fix For: JBossAS-3.2.6 Final > Attachments: JBossFailOverError.txt > > > See the attachment JBossFailOverError.txt for more details. > Abstract: I have a 2 node cluster running JbossMQHA. If the Master node is > disconnect from the Network, the slave assumes the master role. But when the > original Master comes back on-line, it reassumes the Master role, but my > subscriber is never notified of the 2nd fail-over and I am unable to publish > on the slave for about 5 minutes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBAS-35) InvalidDestinationException after Cluster Master failover
[ http://jira.jboss.com/jira/browse/JBAS-35?page=comments#action_12310827 ] Ovidiu Feodorov commented on JBAS-35: - Correction to the previous comment: the problem only shows in JBoss versions older than 3.2.6. Since 3.2.6, JBoss uses JGroups 2.2.7 which fixes the problem. A detailed explanation follows. At step 7 (see previous comment), with JGroups < 2.2.7, the node A initiates a partition merge and remains the coordinator of the healed partition. Based on this configuration, the DRM layer decides that A has been elected new master, and because is still the current master, S1 continues to run. At step 8, the node B runs into a race condition when as the result of the merge, it receives a view update where A is coordinator while B's replicant map hasn't been updated yet and it only contains B. Due to this race condition, B decides that has been elected new master, and because is still the current master, S2 continues to run. JGroups 2.2.7 solves the problem by having A leave the partition and re-join, which is the correct thing to do anyway. The steps 7 and 8 in this case are: At step 7, A leaves and re-joins the partition, its DRM layer decides that A cannot be master anymore, so S1 stops. At step 8, B stays master, so S2 continues to run. > InvalidDestinationException after Cluster Master failover > - > > Key: JBAS-35 > URL: http://jira.jboss.com/jira/browse/JBAS-35 > Project: JBoss Application Server > Type: Bug > Components: Clustering > Versions: JBossAS-3.2.5 Final > Reporter: Scott M Stark > Assignee: Ovidiu Feodorov > Fix For: JBossAS-3.2.7 Final > Attachments: JBossFailOverError.txt > > > See the attachment JBossFailOverError.txt for more details. > Abstract: I have a 2 node cluster running JbossMQHA. If the Master node is > disconnect from the Network, the slave assumes the master role. But when the > original Master comes back on-line, it reassumes the Master role, but my > subscriber is never notified of the 2nd fail-over and I am unable to publish > on the slave for about 5 minutes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
