[GLASSFISH-16467] Support for conventional peer broker clusters with Berkeley DB Created: 27/Apr/11  Updated: 23/Oct/12

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Satish Kumar Assignee: David Zhao
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms4candidate

 Description   

MQ 4.6 is introducing support for Oracle Berkeley DB as a persistent store type to address the elasticity requirements. BDB is a light-weight, highly scalable, embeddable, transactional database with a very low memory foot-print.

This requires changes to the configure-jms-cluster CLI command to enable users to configure this option and to the broker start-up properties that are passed in from the ActiveJMSResourceAdapter at start-up time.






[GLASSFISH-11721] GF does not allow all required passwords to be passed to managed MQ broker Created: 24/Mar/10  Updated: 12/Nov/12  Resolved: 12/Nov/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 3.1
Fix Version/s: 4.0_b63

Type: Improvement Priority: Major
Reporter: Satish Kumar Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,721
Tags: ee7ri_cleanup_deferred, jms4candidate

 Description   

A MQ password file allows you to specify

o keystore password (imq.keystore.password)
o LDAP repository password (imq.user_repository.ldap.password)
o JDBC database password (imq.persist.jdbc.password)
o imqcmd password (imq.imqcmd.password)
o broker bridge service manager administrator password
(imq.bridge.admin.password)

This is normally done by passing a password file to the
broker. However Glassfish also passes in a password file on the
command line, which overrides any password file configured in the
broker properties. Currently, GF does not provide users the option to configure
and use the above mentioned properties. We need a way to enable this in GF.



 Comments   
Comment by Nigel Deakin [ 07/May/10 ]

Following changes to MQ 4.5, Glassfish no longer needs to use a password file to
pass passwords to the managed broker. Updating issue summary accordingly.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

Comment by Simon Meng [ 12/Nov/12 ]

Currently, user can set the mq required passwords via GF jms-service properties. GF call setBrokerProps method to pass these properties to jmsra. jmsra can get the required passwords from broker properties.
GF support password aliases process. That means when setting jms-service properties, user can use plain text or password aliases as propterty value.





[GLASSFISH-7717] Wrong handling of RuntimeExceptions in JMS cluster Created: 14/Apr/09  Updated: 02/Nov/12

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 9.1peur2
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: friedeks Assignee: David Zhao
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 7,717
Status Whiteboard:

v3_exclude, v2.1.1_exclude

Tags: bj-reviewed

 Description   

I installed a v2.1 cluster with two nodes and set up a default jms
ConnectionFactory and logical + physical queue.
I composed a testcase with one MDB doing nothing but throwing a RuntimeException.
The MDB was configured with "EndpointExceptionRedeliveryAttempts=5" and deployed
to the cluster.
A JavaSE Client uses JNDI to send 10000 transactional messages to the queue.
The load gets distributed evenly between the two cluster instances. Instance one
behaves as expected and retries 5 times before moving the messages to DMQ.
Instance two instead seems to ignore EndpointExceptionRedeliveryAttempts and
keeps trying to deliver the bad messages. Instance two loops forever using a lot
of CPU. The Queue shows around 5000 "Not ACK" messages.

The same testcase runs flawlessly in a non-clustered environment.



 Comments   
Comment by Satish Kumar [ 09/Sep/09 ]

This is a v2.1 issue not relevant for V3. Hence adding 'v3_exclude' in the
status whiteboard.

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Simon Meng [ 24/Oct/12 ]

I can't reproduce the described issue. The expected RuntimeException appeared. There is no infinite loop.

But I found other issue in my testing. When sending a message from the standalone java client to queue, the MDB behaves as expected and retries 5 times, we can see 6 RuntimeExceptions. Then the message was moved to DMQ. It looks everything works fine at this point. But when I restart domain and server, the MDB throws 6 RuntimeExceptions again. The message also enters queue and marked as "UnAck". Each time I retart domain, the MDB still throws 6 RuntimeExceptions. It looks to me the behavior is not correct. The message has been moved to the DMQ, why it is delivered again and again when domain restart?

Comment by Simon Meng [ 02/Nov/12 ]

The "other issue" that simeng_oracle noticed in his testing as mentioned in his above comment - that involves a transacted sender client and restart domain is a MQ bug MQ-227.





Generated at Sat Apr 25 03:01:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.